[jira] [Assigned] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov reassigned IGNITE-8550:
Assignee: Ilya Kazakov (was: Moldachev Sergey)
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Ilya Kazakov
>Priority: Minor
> Labels: newbie
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499892#comment-17499892
]
Ilya Kazakov commented on IGNITE-8550:
--
[~smoldachev] I want to assign this ticket on myself. I believe you will not
have any objections.
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16484) sqlOnheapCacheEnabled leads to B+Tree corruption
Ilya Kazakov created IGNITE-16484:
-
Summary: sqlOnheapCacheEnabled leads to B+Tree corruption
Key: IGNITE-16484
URL: https://issues.apache.org/jira/browse/IGNITE-16484
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.12
Reporter: Ilya Kazakov
This code leads to B+Tree corruption:
{code:java}
public static void main(String[] args) {
IgniteConfiguration cfg = new IgniteConfiguration()
.setCacheConfiguration(new CacheConfiguration()
.setSqlOnheapCacheEnabled(true)
.setName("PERSON")
.setIndexedTypes(PersonKey.class, Integer.class));
Ignite ignite = Ignition.start(cfg);
try (IgniteCache cache = ignite.cache("PERSON")) {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
cache.put(new PersonKey(i), i);
if (i % 100 == 0)
System.out.println(i);
}
}
}
private static class PersonKey {
@QuerySqlField
private long id;
public PersonKey(long id) {
this.id = id;
}
}{code}
{code:java}
class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
B+Tree is corrupted [groupId=-1938387115, pageIds=[844420635166787],
cacheId=-1938387115, cacheName=PERSON, indexName=_key_PK, msg=Runtime failure
on row: Row@6c2ed0cd[ key: org.apache.ignite.examples.CacheStore$PersonKey
[idHash=2107543287, hash=-1581735888, id=4870], val: 4870 ][ ]]
at
org.apache.ignite.internal.cache.query.index.sorted.inline.InlineIndexTree.corruptedTreeException(InlineIndexTree.java:585)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2572)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2512)
at
org.apache.ignite.internal.cache.query.index.sorted.inline.InlineIndexImpl.putx(InlineIndexImpl.java:265)
at
org.apache.ignite.internal.cache.query.index.sorted.inline.InlineIndexImpl.onUpdate(InlineIndexImpl.java:247)
at
org.apache.ignite.internal.cache.query.index.IndexProcessor.updateIndex(IndexProcessor.java:452)
at
org.apache.ignite.internal.cache.query.index.IndexProcessor.updateIndexes(IndexProcessor.java:295)
at
org.apache.ignite.internal.cache.query.index.IndexProcessor.store(IndexProcessor.java:142)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2548)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:422)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2674)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1750)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1725)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:449)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2331)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2541)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2004)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1821)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1694)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:481)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:441)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1147)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:615)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2573)
at
[jira] [Updated] (IGNITE-16043) AssertionError in BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-16043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-16043:
--
Issue Type: Bug (was: Improvement)
> AssertionError in BinaryObjectBuilder
> -
>
> Key: IGNITE-16043
> URL: https://issues.apache.org/jira/browse/IGNITE-16043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.11
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
>
> AssertionError in this code (run java with -ea key):
> {{}}
>
>
> {code:java}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObjectBuilder;
> public class Ae {
> public static void main(String[] args) {
> try(Ignite ignite = Ignition.start()){
> BinaryObjectBuilder builder =
> ignite.binary().builder(Ae.class.getName()).setField("w", "wewe");
> String f = builder.getField("field");
> System.out.println(f);
> }
> }
> } {code}
>
>
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:481)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:543)
> at org.apache.ignite.examples.Ae.main(Ae.java:11){code}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16043) AssertionError in BinaryObjectBuilder
Ilya Kazakov created IGNITE-16043:
-
Summary: AssertionError in BinaryObjectBuilder
Key: IGNITE-16043
URL: https://issues.apache.org/jira/browse/IGNITE-16043
Project: Ignite
Issue Type: Improvement
Components: binary
Affects Versions: 2.11
Reporter: Ilya Kazakov
AssertionError in this code (run java with -ea key):
{{}}
{code:java}
import org.apache.ignite.Ignite;
import org.apache.ignite.Ignition;
import org.apache.ignite.binary.BinaryObjectBuilder;
public class Ae {
public static void main(String[] args) {
try(Ignite ignite = Ignition.start()){
BinaryObjectBuilder builder =
ignite.binary().builder(Ae.class.getName()).setField("w", "wewe");
String f = builder.getField("field");
System.out.println(f);
}
}
} {code}
{code:java}
Exception in thread "main" java.lang.AssertionError
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:481)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:543)
at org.apache.ignite.examples.Ae.main(Ae.java:11){code}
{{}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16043) AssertionError in BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-16043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov reassigned IGNITE-16043:
-
Assignee: Ilya Kazakov
> AssertionError in BinaryObjectBuilder
> -
>
> Key: IGNITE-16043
> URL: https://issues.apache.org/jira/browse/IGNITE-16043
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.11
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
>
> AssertionError in this code (run java with -ea key):
> {{}}
>
>
> {code:java}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObjectBuilder;
> public class Ae {
> public static void main(String[] args) {
> try(Ignite ignite = Ignition.start()){
> BinaryObjectBuilder builder =
> ignite.binary().builder(Ae.class.getName()).setField("w", "wewe");
> String f = builder.getField("field");
> System.out.println(f);
> }
> }
> } {code}
>
>
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:481)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:543)
> at org.apache.ignite.examples.Ae.main(Ae.java:11){code}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-15921) Vulnerability in thin client protocol leads to OOM
Ilya Kazakov created IGNITE-15921: - Summary: Vulnerability in thin client protocol leads to OOM Key: IGNITE-15921 URL: https://issues.apache.org/jira/browse/IGNITE-15921 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 2.11 Reporter: Ilya Kazakov As thin client protocol interprets first 4 bytes as message size and allocate array for it. Any "big" 4 bytes sent on thin client port could leads to OOM. Some ideas to resolve: - print WARN in case of big client message - allocate array not for all message, but allocate it gradually. - read more then first4 bytes to understand is it real client message, or it is some trash. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15807) In case of port is absent in IgniteClient first of all try connect on default port.
[ https://issues.apache.org/jira/browse/IGNITE-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440186#comment-17440186 ] Ilya Kazakov commented on IGNITE-15807: --- [~ptupitsyn] , please review again > In case of port is absent in IgniteClient first of all try connect on default > port. > --- > > Key: IGNITE-15807 > URL: https://issues.apache.org/jira/browse/IGNITE-15807 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.11 >Reporter: Ilya Kazakov >Assignee: Ilya Kazakov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Now if in ClientConfiguration address specified without port, client will try > to connect to default port range in random order. But often server listen on > default port. This random order leads to unexpected connection time. > Will be better if firstly client will try to connect to default port, before > randomly scan all port range. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15807) In case of port is absent in IgniteClient first of all try connect on default port.
[ https://issues.apache.org/jira/browse/IGNITE-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433559#comment-17433559 ] Ilya Kazakov commented on IGNITE-15807: --- https://github.com/apache/ignite/pull/9522 > In case of port is absent in IgniteClient first of all try connect on default > port. > --- > > Key: IGNITE-15807 > URL: https://issues.apache.org/jira/browse/IGNITE-15807 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Ilya Kazakov >Assignee: Ilya Kazakov >Priority: Minor > > Now if in ClientConfiguration address specified without port, client will try > to connect to default port range in random order. But often server listen on > default port. This random order leads to unexpected connection time. > Will be better if firstly client will try to connect to default port, before > randomly scan all port range. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15807) In case of port is absent in IgniteClient first of all try connect on default port.
Ilya Kazakov created IGNITE-15807: - Summary: In case of port is absent in IgniteClient first of all try connect on default port. Key: IGNITE-15807 URL: https://issues.apache.org/jira/browse/IGNITE-15807 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Ilya Kazakov Assignee: Ilya Kazakov Now if in ClientConfiguration address specified without port, client will try to connect to default port range in random order. But often server listen on default port. This random order leads to unexpected connection time. Will be better if firstly client will try to connect to default port, before randomly scan all port range. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15740) Log topology snapshot after baseline was changed via baselineAutoadjusted
Ilya Kazakov created IGNITE-15740: - Summary: Log topology snapshot after baseline was changed via baselineAutoadjusted Key: IGNITE-15740 URL: https://issues.apache.org/jira/browse/IGNITE-15740 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.11 Reporter: Ilya Kazakov When baseline was changed via baselineAutoadjustment there are no any messages in console (in case if logs are disabled) or there is only one simple INFO with enabled logs: INFO: Baseline auto-adjust will be executed right now. Ideal if the topology snapshot (with baseline info) will be printed: Topology snapshot [ver=5, locNode=c4129aae, servers=3, clients=0, state=ACTIVE, CPUs=8, offheap=19.0GB, heap=21.0GB] ^-- Baseline [id=0, size=3, online=3, offline=0] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-15322:
--
Issue Type: Bug (was: Improvement)
> System tasks should run without any explicitly granted permissions
> --
>
> Key: IGNITE-15322
> URL: https://issues.apache.org/jira/browse/IGNITE-15322
> Project: Ignite
> Issue Type: Bug
> Components: compute, security
>Reporter: Ilya Kazakov
>Priority: Minor
>
> For example, this code needs TASK_EXECUTE permissions.
> {code:java}
> Affinity affinity = ignite.affinity("TEST");
> affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
> This is unexpected behavior, because:
> - the task started implicitly (under the hood), customer should not to know
> about it.
> - this is a system task (not defined by a customer), the tasks needs for a
> normal grid workflow.
> Also, I suppose there are any other implicitly tasks, which could lead to
> unexpected behavior (need permissions).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15322) System tasks should run without any explicitly granted permissions
Ilya Kazakov created IGNITE-15322:
-
Summary: System tasks should run without any explicitly granted
permissions
Key: IGNITE-15322
URL: https://issues.apache.org/jira/browse/IGNITE-15322
Project: Ignite
Issue Type: Improvement
Components: compute, security
Reporter: Ilya Kazakov
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
- the task started implicitly (under the hood), customer should not to know
about it.
- this is a system task (not defined by a customer), the tasks needs for a
normal grid workflow.
Also, I suppose there are any other implicitly tasks, which could lead to
unexpected behavior (need permissions).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15192) Fix race in Checkpointer listeners invocation and illegal Checkpointer-heartbeat update from different threads
[
https://issues.apache.org/jira/browse/IGNITE-15192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-15192:
--
Description:
It is about race which was detected in
https://issues.apache.org/jira/browse/IGNITE-15099.
The fix from the ticket above fixed the wrong heartbeat, but do not fix a race,
which allows checkpointer thread go ahead and do not await on
ctx0.awaitPendingTasksFinished() (in ChecpointWorkflow.markCheckpointBegin ),
which leads to:
- checkpointer thread enter in blocking section
- and after this a checkpointer thread hertbeat could be updated by prallel
thread.
{code:java}
// CheckpointContextImpl#executor
@Override public Executor executor() {
return asyncRunner == null ? null : cmd -> {
try {
GridFutureAdapter res = new GridFutureAdapter<>();
res.listen(fut -> heartbeatUpdater.updateHeartbeat()); //
Listener is invoked concurrently with pending future finish
asyncRunner.execute(U.wrapIgniteFuture(cmd, res));
pendingTaskFuture.add(res);
}
catch (RejectedExecutionException e) {
assert false : "A task should never be rejected by async
runner";
}
};
}
{code}
{code:java}
// Checkpointer#waitCheckpointEvent
try {
synchronized (this) {
long remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
System.nanoTime());
while (remaining > 0 && !isCancelled()) {
blockingSectionBegin();
try {
wait(remaining);
// At this point and till blockingSectionEnd call heartbeat
should be equal to Long.MAX_VALUE
remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
System.nanoTime());
}
finally {
blockingSectionEnd();
}
}
}
}
{code}
Discussion is here:
[https://lists.apache.org/thread.html/r789abd9005d70a8fa1de29d3af394069e859ca6e1eea8bfd3e3e0494%40%3Cdev.ignite.apache.org%3E]
was:
It is about race which was detected in
https://issues.apache.org/jira/browse/IGNITE-15099.
{code:java}
// CheckpointContextImpl#executor
@Override public Executor executor() {
return asyncRunner == null ? null : cmd -> {
try {
GridFutureAdapter res = new GridFutureAdapter<>();
res.listen(fut -> heartbeatUpdater.updateHeartbeat()); //
Listener is invoked concurrently with pending future finish
asyncRunner.execute(U.wrapIgniteFuture(cmd, res));
pendingTaskFuture.add(res);
}
catch (RejectedExecutionException e) {
assert false : "A task should never be rejected by async
runner";
}
};
}
{code}
{code:java}
// Checkpointer#waitCheckpointEvent
try {
synchronized (this) {
long remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
System.nanoTime());
while (remaining > 0 && !isCancelled()) {
blockingSectionBegin();
try {
wait(remaining);
// At this point and till blockingSectionEnd call heartbeat
should be equal to Long.MAX_VALUE
remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
System.nanoTime());
}
finally {
blockingSectionEnd();
}
}
}
}
{code}
Discussion is here:
https://lists.apache.org/thread.html/r789abd9005d70a8fa1de29d3af394069e859ca6e1eea8bfd3e3e0494%40%3Cdev.ignite.apache.org%3E
> Fix race in Checkpointer listeners invocation and illegal
> Checkpointer-heartbeat update from different threads
> --
>
> Key: IGNITE-15192
> URL: https://issues.apache.org/jira/browse/IGNITE-15192
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is about race which was detected in
> https://issues.apache.org/jira/browse/IGNITE-15099.
> The fix from the ticket above fixed the wrong heartbeat, but do not fix a
> race, which allows checkpointer thread go ahead and do not await on
> ctx0.awaitPendingTasksFinished() (in ChecpointWorkflow.markCheckpointBegin ),
> which leads to:
> - checkpointer thread enter in blocking section
> - and after this a checkpointer thread hertbeat could be updated by prallel
> thread.
>
> {code:java}
> // CheckpointContextImpl#executor
> @Override public Executor executor() {
> return asyncRunner == null ? null : cmd -> {
> try {
> GridFutureAdapter res = new GridFutureAdapter<>();
>
[jira] [Created] (IGNITE-15267) A lot of spam in logs on thick client: "Unable to save statistics obsolescence info on non server node."
Ilya Kazakov created IGNITE-15267: - Summary: A lot of spam in logs on thick client: "Unable to save statistics obsolescence info on non server node." Key: IGNITE-15267 URL: https://issues.apache.org/jira/browse/IGNITE-15267 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.10 Reporter: Ilya Kazakov In logs on thick client there are a lot of such messages: 2021-08-05 18:28:26,870 17371453 INFO [grid-timeout-worker-#22%member-checkin-data-s] java.JavaLogger ( JavaLogger.java: 284) - Unable to save statistics obsolescence info on non server node. It looks like unexpected calls to save stat on thick client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15192) Fix race in Checkpointer listeners invocation and illegal Checkpointer-heartbeat update from different threads
[
https://issues.apache.org/jira/browse/IGNITE-15192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-15192:
--
Description:
It is about race which was detected in
https://issues.apache.org/jira/browse/IGNITE-15099.
{code:java}
// CheckpointContextImpl#executor
@Override public Executor executor() {
return asyncRunner == null ? null : cmd -> {
try {
GridFutureAdapter res = new GridFutureAdapter<>();
res.listen(fut -> heartbeatUpdater.updateHeartbeat()); //
Listener is invoked concurrently with pending future finish
asyncRunner.execute(U.wrapIgniteFuture(cmd, res));
pendingTaskFuture.add(res);
}
catch (RejectedExecutionException e) {
assert false : "A task should never be rejected by async
runner";
}
};
}
{code}
{code:java}
// Checkpointer#waitCheckpointEvent
try {
synchronized (this) {
long remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
System.nanoTime());
while (remaining > 0 && !isCancelled()) {
blockingSectionBegin();
try {
wait(remaining);
// At this point and till blockingSectionEnd call heartbeat
should be equal to Long.MAX_VALUE
remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
System.nanoTime());
}
finally {
blockingSectionEnd();
}
}
}
}
{code}
Discussion is here:
https://lists.apache.org/thread.html/r789abd9005d70a8fa1de29d3af394069e859ca6e1eea8bfd3e3e0494%40%3Cdev.ignite.apache.org%3E
> Fix race in Checkpointer listeners invocation and illegal
> Checkpointer-heartbeat update from different threads
> --
>
> Key: IGNITE-15192
> URL: https://issues.apache.org/jira/browse/IGNITE-15192
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
>
> It is about race which was detected in
> https://issues.apache.org/jira/browse/IGNITE-15099.
>
> {code:java}
> // CheckpointContextImpl#executor
> @Override public Executor executor() {
> return asyncRunner == null ? null : cmd -> {
> try {
> GridFutureAdapter res = new GridFutureAdapter<>();
> res.listen(fut -> heartbeatUpdater.updateHeartbeat()); //
> Listener is invoked concurrently with pending future finish
> asyncRunner.execute(U.wrapIgniteFuture(cmd, res));
> pendingTaskFuture.add(res);
> }
> catch (RejectedExecutionException e) {
> assert false : "A task should never be rejected by async
> runner";
> }
> };
> }
> {code}
>
> {code:java}
> // Checkpointer#waitCheckpointEvent
> try {
> synchronized (this) {
> long remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
> System.nanoTime());
> while (remaining > 0 && !isCancelled()) {
> blockingSectionBegin();
> try {
> wait(remaining);
> // At this point and till blockingSectionEnd call heartbeat
> should be equal to Long.MAX_VALUE
> remaining = U.nanosToMillis(scheduledCp.nextCpNanos -
> System.nanoTime());
> }
> finally {
> blockingSectionEnd();
> }
> }
> }
> }
> {code}
> Discussion is here:
> https://lists.apache.org/thread.html/r789abd9005d70a8fa1de29d3af394069e859ca6e1eea8bfd3e3e0494%40%3Cdev.ignite.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15192) Fix race in Checkpointer listeners invocation and illegal Checkpointer-heartbeat update from different threads
Ilya Kazakov created IGNITE-15192: - Summary: Fix race in Checkpointer listeners invocation and illegal Checkpointer-heartbeat update from different threads Key: IGNITE-15192 URL: https://issues.apache.org/jira/browse/IGNITE-15192 Project: Ignite Issue Type: Improvement Affects Versions: 2.10 Reporter: Ilya Kazakov Assignee: Ilya Kazakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14806) Synchronize localListener class name via discovery for displaying in CONTINUOUS_QUERIES system view
Ilya Kazakov created IGNITE-14806: - Summary: Synchronize localListener class name via discovery for displaying in CONTINUOUS_QUERIES system view Key: IGNITE-14806 URL: https://issues.apache.org/jira/browse/IGNITE-14806 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.10 Reporter: Ilya Kazakov Assignee: Ilya Kazakov CQ system view has LOCAL_LISTENER and LOCAL_TRANSFORMED_LISTENER fields. But these fields are not null only in case when we query the system view from the node which was deploying the CQ. In any other case, these fields will be null, because localListemer and localTransformedListened are not deployed on remote nodes. Thus to understand which localListener has the CQ, we should query system view from the node which was deploying the CQ. Often CQ client nodes deploy CQ, but there is no way to query CQ on the client node. It turns out there are many situations where we cannot find out which localListener is being used. I propose to make the localListener class name synchronized between nodes via discovery. Not deploying localListener on remote nodes, but just name synchronization. And this name will be used for LOCAL_LISTENER field in system view in case when localListened are not deployed on the node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-14569: -- Description: It will be good to have an api to list all created data structures: latches, atomics and so on. So it could be a system view. There is system views for caches, for nodes, for continuous queries: https://ignite.apache.org/docs/latest/monitoring-metrics/system-views. It needs a system views for data structures. In general, each data structure system view must have the same fields as the method arguments that creates the data structure. For example system view for latches should have such fields: name - name of the latch initialCnt - count when latch was created (if this data is available) cnt - current latch count autoDel - does the latch automatically delete when its count reaches zero. Queue system view: name - name of the queue capacity - capacity of the queue size - current size of the queue Set system view: name - name of the set size - current size of the set Atomics system view: name - name of the atomic initVal - initial value of the atomic currentVal - current value of the atomic type - SEQUENCE | LONG | REFERENCE was: It will be good to have an api to list all created data structures: latches, atomics and so on. So it could be a system view. There is system views for caches, for nodes, for continuous queries. It needs a system view (or views) for data structures. > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Priority: Minor > Labels: newbie > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries: > https://ignite.apache.org/docs/latest/monitoring-metrics/system-views. > It needs a system views for data structures. In general, each data structure > system view must have the same fields as the method arguments that creates > the data structure. > For example system view for latches should have such fields: > name - name of the latch > initialCnt - count when latch was created (if this data is available) > cnt - current latch count > autoDel - does the latch automatically delete when its count reaches zero. > Queue system view: > name - name of the queue > capacity - capacity of the queue > size - current size of the queue > Set system view: > name - name of the set > size - current size of the set > Atomics system view: > name - name of the atomic > initVal - initial value of the atomic > currentVal - current value of the atomic > type - SEQUENCE | LONG | REFERENCE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-14569: -- Description: It will be good to have an api to list all created data structures: latches, atomics and so on. So it could be a system view. There is system views for caches, for nodes, for continuous queries: [https://ignite.apache.org/docs/latest/monitoring-metrics/system-views]. It needs a system views for data structures. In general, each data structure system view must have the same fields as the method arguments that creates the data structure. For example system view for *latches* should have such fields: name - name of the latch initialCnt - count when latch was created (if this data is available) cnt - current latch count autoDel - does the latch automatically delete when its count reaches zero. *Queue system view:* name - name of the queue capacity - capacity of the queue size - current size of the queue *Set system view:* name - name of the set size - current size of the set *Atomics system view:* name - name of the atomic initVal - initial value of the atomic currentVal - current value of the atomic type - SEQUENCE | LONG | REFERENCE was: It will be good to have an api to list all created data structures: latches, atomics and so on. So it could be a system view. There is system views for caches, for nodes, for continuous queries: https://ignite.apache.org/docs/latest/monitoring-metrics/system-views. It needs a system views for data structures. In general, each data structure system view must have the same fields as the method arguments that creates the data structure. For example system view for latches should have such fields: name - name of the latch initialCnt - count when latch was created (if this data is available) cnt - current latch count autoDel - does the latch automatically delete when its count reaches zero. Queue system view: name - name of the queue capacity - capacity of the queue size - current size of the queue Set system view: name - name of the set size - current size of the set Atomics system view: name - name of the atomic initVal - initial value of the atomic currentVal - current value of the atomic type - SEQUENCE | LONG | REFERENCE > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Priority: Minor > Labels: newbie > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries: > [https://ignite.apache.org/docs/latest/monitoring-metrics/system-views]. > It needs a system views for data structures. In general, each data structure > system view must have the same fields as the method arguments that creates > the data structure. > For example system view for *latches* should have such fields: > name - name of the latch > initialCnt - count when latch was created (if this data is available) > cnt - current latch count > autoDel - does the latch automatically delete when its count reaches zero. > *Queue system view:* > name - name of the queue > capacity - capacity of the queue > size - current size of the queue > > *Set system view:* > name - name of the set > size - current size of the set > > *Atomics system view:* > name - name of the atomic > initVal - initial value of the atomic > currentVal - current value of the atomic > type - SEQUENCE | LONG | REFERENCE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14634) NPE in ShmemClient
[
https://issues.apache.org/jira/browse/IGNITE-14634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-14634:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> NPE in ShmemClient
> --
>
> Key: IGNITE-14634
> URL: https://issues.apache.org/jira/browse/IGNITE-14634
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.10
>Reporter: Ilya Kazakov
>Priority: Major
>
> This code works correctly on 2.7, but do not work on 2.8, 2.9 and 2.10
> {code:java}
> public class T1 {
> static int sharedMemPort = 37235;
> public static void main(String[] args) {
> Ignition.start(getConf("I1"));
> Ignition.start(getConf("I2"));
> }
> public static IgniteConfiguration getConf(String instanceName) {
> return new
> IgniteConfiguration().setIgniteInstanceName(instanceName).setCommunicationSpi(new
> TcpCommunicationSpi().setSharedMemoryPort(sharedMemPort));
> }
> }{code}
> On 2.10
> {code:java}
> [2021-04-23
> 13:06:20,562][ERROR][exchange-worker-#129%I2%][TcpCommunicationSpi] Failed to
> send message to remote node [node=TcpDiscoveryNode
> [id=7469805f-1097-4e49-a0d9-3474a6a792bb,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47500,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
> 192.168.49.1], sockAddrs=HashSet [/172.17.0.1:47500, /192.168.49.1:47500,
> /0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.1.105:47500],
> discPort=47500, order=1, intOrder=1, lastExchangeTime=1619154380497,
> loc=false, ver=2.11.0#20210422-sha1:bec58b00, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridDhtPartitionsSingleMessage
> [parts=HashMap {-2100569601=GridDhtPartitionMap [moving=0,
> top=AffinityTopologyVersion [topVer=-1, minorTopVer=0], updateSeq=1,
> size=0]}, partCntrs=HashMap {-2100569601=CachePartitionPartialCountersMap
> {}}, partsSizes=null, partHistCntrs=null, err=null, client=false,
> exchangeStartTime=1619154380524, finishMsg=null,
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=f3b31869-bea3-406c-a8a3-6fe5a502d8c4,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47501,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
> 192.168.49.1], sockAddrs=HashSet [/192.168.49.1:47501,
> /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /192.168.1.105:47501,
> /172.17.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1619154380527, loc=true, ver=2.11.0#20210422-sha1:bec58b00,
> isClient=false], topVer=2, msgTemplate=null,
> span=org.apache.ignite.internal.processors.tracing.NoopSpan@4773b242,
> nodeId8=f3b31869, msg=null, type=NODE_JOINED, tstamp=1619154380517],
> nodeId=f3b31869, evt=NODE_JOINED], lastVer=GridCacheVersion [topVer=0,
> order=1619154379141, nodeOrder=0], super=GridCacheMessage [msgId=1,
> depInfo=null, lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1,
> minorTopVer=0], err=null, skipPrepare=false][2021-04-23
> 13:06:20,562][ERROR][exchange-worker-#129%I2%][TcpCommunicationSpi] Failed to
> send message to remote node [node=TcpDiscoveryNode
> [id=7469805f-1097-4e49-a0d9-3474a6a792bb,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47500,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
> 192.168.49.1], sockAddrs=HashSet [/172.17.0.1:47500, /192.168.49.1:47500,
> /0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.1.105:47500],
> discPort=47500, order=1, intOrder=1, lastExchangeTime=1619154380497,
> loc=false, ver=2.11.0#20210422-sha1:bec58b00, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridDhtPartitionsSingleMessage
> [parts=HashMap {-2100569601=GridDhtPartitionMap [moving=0,
> top=AffinityTopologyVersion [topVer=-1, minorTopVer=0], updateSeq=1,
> size=0]}, partCntrs=HashMap {-2100569601=CachePartitionPartialCountersMap
> {}}, partsSizes=null, partHistCntrs=null, err=null, client=false,
> exchangeStartTime=1619154380524, finishMsg=null,
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=f3b31869-bea3-406c-a8a3-6fe5a502d8c4,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47501,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
> 192.168.49.1], sockAddrs=HashSet [/192.168.49.1:47501,
>
[jira] [Created] (IGNITE-14634) NPE in ShmemClient
Ilya Kazakov created IGNITE-14634:
-
Summary: NPE in ShmemClient
Key: IGNITE-14634
URL: https://issues.apache.org/jira/browse/IGNITE-14634
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.10
Reporter: Ilya Kazakov
This code works correctly on 2.7, but do not work on 2.8, 2.9 and 2.10
{code:java}
public class T1 {
static int sharedMemPort = 37235;
public static void main(String[] args) {
Ignition.start(getConf("I1"));
Ignition.start(getConf("I2"));
}
public static IgniteConfiguration getConf(String instanceName) {
return new
IgniteConfiguration().setIgniteInstanceName(instanceName).setCommunicationSpi(new
TcpCommunicationSpi().setSharedMemoryPort(sharedMemPort));
}
}{code}
On 2.10
{code:java}
[2021-04-23 13:06:20,562][ERROR][exchange-worker-#129%I2%][TcpCommunicationSpi]
Failed to send message to remote node [node=TcpDiscoveryNode
[id=7469805f-1097-4e49-a0d9-3474a6a792bb,
consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47500,
addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
192.168.49.1], sockAddrs=HashSet [/172.17.0.1:47500, /192.168.49.1:47500,
/0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.1.105:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1619154380497, loc=false,
ver=2.11.0#20210422-sha1:bec58b00, isClient=false], msg=GridIoMessage [plc=2,
topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false,
msg=GridDhtPartitionsSingleMessage [parts=HashMap
{-2100569601=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=-1, minorTopVer=0], updateSeq=1, size=0]}, partCntrs=HashMap
{-2100569601=CachePartitionPartialCountersMap {}}, partsSizes=null,
partHistCntrs=null, err=null, client=false, exchangeStartTime=1619154380524,
finishMsg=null, super=GridDhtPartitionsAbstractMessage
[exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2,
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=f3b31869-bea3-406c-a8a3-6fe5a502d8c4,
consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47501,
addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
192.168.49.1], sockAddrs=HashSet [/192.168.49.1:47501,
/0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /192.168.1.105:47501,
/172.17.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1619154380527, loc=true, ver=2.11.0#20210422-sha1:bec58b00,
isClient=false], topVer=2, msgTemplate=null,
span=org.apache.ignite.internal.processors.tracing.NoopSpan@4773b242,
nodeId8=f3b31869, msg=null, type=NODE_JOINED, tstamp=1619154380517],
nodeId=f3b31869, evt=NODE_JOINED], lastVer=GridCacheVersion [topVer=0,
order=1619154379141, nodeOrder=0], super=GridCacheMessage [msgId=1,
depInfo=null, lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1,
minorTopVer=0], err=null, skipPrepare=false][2021-04-23
13:06:20,562][ERROR][exchange-worker-#129%I2%][TcpCommunicationSpi] Failed to
send message to remote node [node=TcpDiscoveryNode
[id=7469805f-1097-4e49-a0d9-3474a6a792bb,
consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47500,
addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
192.168.49.1], sockAddrs=HashSet [/172.17.0.1:47500, /192.168.49.1:47500,
/0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.1.105:47500],
discPort=47500, order=1, intOrder=1, lastExchangeTime=1619154380497, loc=false,
ver=2.11.0#20210422-sha1:bec58b00, isClient=false], msg=GridIoMessage [plc=2,
topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false,
msg=GridDhtPartitionsSingleMessage [parts=HashMap
{-2100569601=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=-1, minorTopVer=0], updateSeq=1, size=0]}, partCntrs=HashMap
{-2100569601=CachePartitionPartialCountersMap {}}, partsSizes=null,
partHistCntrs=null, err=null, client=false, exchangeStartTime=1619154380524,
finishMsg=null, super=GridDhtPartitionsAbstractMessage
[exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2,
minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=f3b31869-bea3-406c-a8a3-6fe5a502d8c4,
consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47501,
addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
192.168.49.1], sockAddrs=HashSet [/192.168.49.1:47501,
/0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /192.168.1.105:47501,
/172.17.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1619154380527, loc=true, ver=2.11.0#20210422-sha1:bec58b00,
isClient=false], topVer=2, msgTemplate=null,
span=org.apache.ignite.internal.processors.tracing.NoopSpan@4773b242,
nodeId8=f3b31869, msg=null, type=NODE_JOINED,
[jira] [Updated] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-14569: -- Description: It will be good to have an api to list all created data structures: latches, atomics and so on. So it could be a system view. There is system views for caches, for nodes, for continuous queries. It needs a system view (or views) for data structures. was:It will be good to have an api to list all created data structures: latches, atomics and so on. So it could be a system view. > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Priority: Minor > Labels: newbie > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries. It needs > a system view (or views) for data structures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14569) Create data structures system view
Ilya Kazakov created IGNITE-14569: - Summary: Create data structures system view Key: IGNITE-14569 URL: https://issues.apache.org/jira/browse/IGNITE-14569 Project: Ignite Issue Type: Improvement Components: data structures Affects Versions: 2.10 Reporter: Ilya Kazakov It will be good to have an api to list all created data structures: latches, atomics and so on. So it could be a system view. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14547) NPE in control.sh if there is unknown argument after --cache indexes_force_rebuild
[
https://issues.apache.org/jira/browse/IGNITE-14547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322195#comment-17322195
]
Ilya Kazakov commented on IGNITE-14547:
---
[~ilyak], could you review please
> NPE in control.sh if there is unknown argument after --cache
> indexes_force_rebuild
> --
>
> Key: IGNITE-14547
> URL: https://issues.apache.org/jira/browse/IGNITE-14547
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ./control.sh --cache indexes_force_rebuild --foo
> gets NPE instead of "Unknown argument: --foo" message
> {code:java}
> java.lang.NullPointerException
> Command [] finished with code: 4
> Error stack trace:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.commandline.cache.CacheIndexesForceRebuild.parseArguments(CacheIndexesForceRebuild.java:210)
> at
> org.apache.ignite.internal.commandline.cache.CacheCommands.parseArguments(CacheCommands.java:97)
> at
> org.apache.ignite.internal.commandline.CommonArgParser.parseAndValidate(CommonArgParser.java:241)
> at
> org.apache.ignite.internal.commandline.CommandHandler.execute(CommandHandler.java:244)
> at
> org.apache.ignite.internal.commandline.CommandHandler.main(CommandHandler.java:141){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14547) NPE in control.sh if there is unknown argument after --cache indexes_force_rebuild
[
https://issues.apache.org/jira/browse/IGNITE-14547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17321908#comment-17321908
]
Ilya Kazakov commented on IGNITE-14547:
---
https://github.com/apache/ignite/pull/9005
> NPE in control.sh if there is unknown argument after --cache
> indexes_force_rebuild
> --
>
> Key: IGNITE-14547
> URL: https://issues.apache.org/jira/browse/IGNITE-14547
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ./control.sh --cache indexes_force_rebuild --foo
> gets NPE instead of "Unknown argument: --foo" message
> {code:java}
> java.lang.NullPointerException
> Command [] finished with code: 4
> Error stack trace:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.commandline.cache.CacheIndexesForceRebuild.parseArguments(CacheIndexesForceRebuild.java:210)
> at
> org.apache.ignite.internal.commandline.cache.CacheCommands.parseArguments(CacheCommands.java:97)
> at
> org.apache.ignite.internal.commandline.CommonArgParser.parseAndValidate(CommonArgParser.java:241)
> at
> org.apache.ignite.internal.commandline.CommandHandler.execute(CommandHandler.java:244)
> at
> org.apache.ignite.internal.commandline.CommandHandler.main(CommandHandler.java:141){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14547) NPE in control.sh if there is unknown argument after --cache indexes_force_rebuild
Ilya Kazakov created IGNITE-14547:
-
Summary: NPE in control.sh if there is unknown argument after
--cache indexes_force_rebuild
Key: IGNITE-14547
URL: https://issues.apache.org/jira/browse/IGNITE-14547
Project: Ignite
Issue Type: Bug
Components: control.sh
Affects Versions: 2.10
Reporter: Ilya Kazakov
Assignee: Ilya Kazakov
./control.sh --cache indexes_force_rebuild --foo
gets NPE instead of "Unknown argument: --foo" message
{code:java}
java.lang.NullPointerException
Command [] finished with code: 4
Error stack trace:
java.lang.NullPointerException
at
org.apache.ignite.internal.commandline.cache.CacheIndexesForceRebuild.parseArguments(CacheIndexesForceRebuild.java:210)
at
org.apache.ignite.internal.commandline.cache.CacheCommands.parseArguments(CacheCommands.java:97)
at
org.apache.ignite.internal.commandline.CommonArgParser.parseAndValidate(CommonArgParser.java:241)
at
org.apache.ignite.internal.commandline.CommandHandler.execute(CommandHandler.java:244)
at
org.apache.ignite.internal.commandline.CommandHandler.main(CommandHandler.java:141){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14177) Query parallelism ignores "NULLS LAST" in "order by" clause
[ https://issues.apache.org/jira/browse/IGNITE-14177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-14177: -- Attachment: (was: NullsLastWithParallels.java) > Query parallelism ignores "NULLS LAST" in "order by" clause > --- > > Key: IGNITE-14177 > URL: https://issues.apache.org/jira/browse/IGNITE-14177 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9.1 >Reporter: Ilya Kazakov >Priority: Major > Attachments: NullsLastWithParallels.java > > > If set QueryParallelism to some value >=2, then "NULLS LAST" is ignored in > "order by clause". > e.g. SELECT * FROM ORDER BY ASC NULLS LAST > A small reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14177) Query parallelism ignores "NULLS LAST" in "order by" clause
[ https://issues.apache.org/jira/browse/IGNITE-14177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-14177: -- Attachment: NullsLastWithParallels.java > Query parallelism ignores "NULLS LAST" in "order by" clause > --- > > Key: IGNITE-14177 > URL: https://issues.apache.org/jira/browse/IGNITE-14177 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9.1 >Reporter: Ilya Kazakov >Priority: Major > Attachments: NullsLastWithParallels.java > > > If set QueryParallelism to some value >=2, then "NULLS LAST" is ignored in > "order by clause". > e.g. SELECT * FROM ORDER BY ASC NULLS LAST > A small reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14177) Query parallelism ignores "NULLS LAST" in "order by" clause
Ilya Kazakov created IGNITE-14177: - Summary: Query parallelism ignores "NULLS LAST" in "order by" clause Key: IGNITE-14177 URL: https://issues.apache.org/jira/browse/IGNITE-14177 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.9.1 Reporter: Ilya Kazakov Attachments: NullsLastWithParallels.java If set QueryParallelism to some value >=2, then "NULLS LAST" is ignored in "order by clause". e.g. SELECT * FROM ORDER BY ASC NULLS LAST A small reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14168) Wrong help-description for `control.sh --cache validate_indexes`
[ https://issues.apache.org/jira/browse/IGNITE-14168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov reassigned IGNITE-14168: - Assignee: Alexey Plotnik (was: Ilya Kazakov) > Wrong help-description for `control.sh --cache validate_indexes` > > > Key: IGNITE-14168 > URL: https://issues.apache.org/jira/browse/IGNITE-14168 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.9.1 >Reporter: Ilya Kazakov >Assignee: Alexey Plotnik >Priority: Minor > > It looks like description for validate_index command was copied from > idle_verify command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14168) Wrong help-description for `control.sh --cache validate_indexes`
[ https://issues.apache.org/jira/browse/IGNITE-14168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-14168: -- Description: It looks like description for validate_index command was copied from idle_verify command. > Wrong help-description for `control.sh --cache validate_indexes` > > > Key: IGNITE-14168 > URL: https://issues.apache.org/jira/browse/IGNITE-14168 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.9.1 >Reporter: Ilya Kazakov >Assignee: Ilya Kazakov >Priority: Minor > > It looks like description for validate_index command was copied from > idle_verify command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14168) Wrong help-description for `control.sh --cache validate_indexes`
Ilya Kazakov created IGNITE-14168: - Summary: Wrong help-description for `control.sh --cache validate_indexes` Key: IGNITE-14168 URL: https://issues.apache.org/jira/browse/IGNITE-14168 Project: Ignite Issue Type: Improvement Components: control.sh Affects Versions: 2.9.1 Reporter: Ilya Kazakov Assignee: Ilya Kazakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13856) Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg, writer)
[
https://issues.apache.org/jira/browse/IGNITE-13856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255341#comment-17255341
]
Ilya Kazakov commented on IGNITE-13856:
---
[~ilyak] I have implemented your advice, if I understood you correctly.
> Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg,
> writer)
> -
>
> Key: IGNITE-13856
> URL: https://issues.apache.org/jira/browse/IGNITE-13856
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Major
> Attachments: LongStringSQL.java
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code:java}
> @Override public void writeMessage(Message msg, MessageWriter writer) {
> if (msg != null) {
> if (buf.hasRemaining()) {
> try {
> writer.beforeInnerMessageWrite()
> writer.setCurrentWriteClass(msg.getClass());
> lastFinished = msg.writeTo(buf, writer);
> }
> finally {
> writer.afterInnerMessageWrite(lastFinished);
> }
> }
> }
> }{code}
> It is going to do multiple invocations of msg.writeTo(). If msg is
> GridH2String, it will to val.getBytes() on every invocation of writeTo(),
> leading to spiking of CPU and RAM usage.
> We should change this module to make sure that all serialization happens only
> once.
>
> Reproducer is attached. If we increase string size in 10 times, then the
> execution time increases more than 10 times.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13856) Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg, writer)
[
https://issues.apache.org/jira/browse/IGNITE-13856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254467#comment-17254467
]
Ilya Kazakov commented on IGNITE-13856:
---
[~ilyak], could you merge it please!
> Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg,
> writer)
> -
>
> Key: IGNITE-13856
> URL: https://issues.apache.org/jira/browse/IGNITE-13856
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Major
> Attachments: LongStringSQL.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> @Override public void writeMessage(Message msg, MessageWriter writer) {
> if (msg != null) {
> if (buf.hasRemaining()) {
> try {
> writer.beforeInnerMessageWrite()
> writer.setCurrentWriteClass(msg.getClass());
> lastFinished = msg.writeTo(buf, writer);
> }
> finally {
> writer.afterInnerMessageWrite(lastFinished);
> }
> }
> }
> }{code}
> It is going to do multiple invocations of msg.writeTo(). If msg is
> GridH2String, it will to val.getBytes() on every invocation of writeTo(),
> leading to spiking of CPU and RAM usage.
> We should change this module to make sure that all serialization happens only
> once.
>
> Reproducer is attached. If we increase string size in 10 times, then the
> execution time increases more than 10 times.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13856) Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg, writer)
[
https://issues.apache.org/jira/browse/IGNITE-13856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253578#comment-17253578
]
Ilya Kazakov commented on IGNITE-13856:
---
[~akalashnikov], I have implemented all your advice. Could you review again,
please.
> Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg,
> writer)
> -
>
> Key: IGNITE-13856
> URL: https://issues.apache.org/jira/browse/IGNITE-13856
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Major
> Attachments: LongStringSQL.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> @Override public void writeMessage(Message msg, MessageWriter writer) {
> if (msg != null) {
> if (buf.hasRemaining()) {
> try {
> writer.beforeInnerMessageWrite()
> writer.setCurrentWriteClass(msg.getClass());
> lastFinished = msg.writeTo(buf, writer);
> }
> finally {
> writer.afterInnerMessageWrite(lastFinished);
> }
> }
> }
> }{code}
> It is going to do multiple invocations of msg.writeTo(). If msg is
> GridH2String, it will to val.getBytes() on every invocation of writeTo(),
> leading to spiking of CPU and RAM usage.
> We should change this module to make sure that all serialization happens only
> once.
>
> Reproducer is attached. If we increase string size in 10 times, then the
> execution time increases more than 10 times.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13856) Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg, writer)
[
https://issues.apache.org/jira/browse/IGNITE-13856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251541#comment-17251541
]
Ilya Kazakov commented on IGNITE-13856:
---
[~akalashnikov] please review
> Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg,
> writer)
> -
>
> Key: IGNITE-13856
> URL: https://issues.apache.org/jira/browse/IGNITE-13856
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Major
> Attachments: LongStringSQL.java
>
>
> {code:java}
> @Override public void writeMessage(Message msg, MessageWriter writer) {
> if (msg != null) {
> if (buf.hasRemaining()) {
> try {
> writer.beforeInnerMessageWrite()
> writer.setCurrentWriteClass(msg.getClass());
> lastFinished = msg.writeTo(buf, writer);
> }
> finally {
> writer.afterInnerMessageWrite(lastFinished);
> }
> }
> }
> }{code}
> It is going to do multiple invocations of msg.writeTo(). If msg is
> GridH2String, it will to val.getBytes() on every invocation of writeTo(),
> leading to spiking of CPU and RAM usage.
> We should change this module to make sure that all serialization happens only
> once.
>
> Reproducer is attached. If we increase string size in 10 times, then the
> execution time increases more than 10 times.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13856) Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg, writer)
[
https://issues.apache.org/jira/browse/IGNITE-13856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251093#comment-17251093
]
Ilya Kazakov commented on IGNITE-13856:
---
https://github.com/apache/ignite/pull/8577
> Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg,
> writer)
> -
>
> Key: IGNITE-13856
> URL: https://issues.apache.org/jira/browse/IGNITE-13856
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Major
> Attachments: LongStringSQL.java
>
>
> {code:java}
> @Override public void writeMessage(Message msg, MessageWriter writer) {
> if (msg != null) {
> if (buf.hasRemaining()) {
> try {
> writer.beforeInnerMessageWrite()
> writer.setCurrentWriteClass(msg.getClass());
> lastFinished = msg.writeTo(buf, writer);
> }
> finally {
> writer.afterInnerMessageWrite(lastFinished);
> }
> }
> }
> }{code}
> It is going to do multiple invocations of msg.writeTo(). If msg is
> GridH2String, it will to val.getBytes() on every invocation of writeTo(),
> leading to spiking of CPU and RAM usage.
> We should change this module to make sure that all serialization happens only
> once.
>
> Reproducer is attached. If we increase string size in 10 times, then the
> execution time increases more than 10 times.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13856) Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg, writer)
Ilya Kazakov created IGNITE-13856:
-
Summary: Superlinear performance of
DirectByteBufferStreamImplV2.writeMessage(msg, writer)
Key: IGNITE-13856
URL: https://issues.apache.org/jira/browse/IGNITE-13856
Project: Ignite
Issue Type: Improvement
Components: binary
Affects Versions: 2.9
Reporter: Ilya Kazakov
Assignee: Ilya Kazakov
Attachments: LongStringSQL.java
{code:java}
@Override public void writeMessage(Message msg, MessageWriter writer) {
if (msg != null) {
if (buf.hasRemaining()) {
try {
writer.beforeInnerMessageWrite()
writer.setCurrentWriteClass(msg.getClass());
lastFinished = msg.writeTo(buf, writer);
}
finally {
writer.afterInnerMessageWrite(lastFinished);
}
}
}
}{code}
It is going to do multiple invocations of msg.writeTo(). If msg is
GridH2String, it will to val.getBytes() on every invocation of writeTo(),
leading to spiking of CPU and RAM usage.
We should change this module to make sure that all serialization happens only
once.
Reproducer is attached. If we increase string size in 10 times, then the
execution time increases more than 10 times.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13765) Incorrect work of predicates (< and >) in where clause with compound primary key.
[ https://issues.apache.org/jira/browse/IGNITE-13765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-13765: -- Description: The combination of these two conditions always gives an empty selection, but the result must not be empty. * Compound primary key (2 or more columns) * In select query in where clause use condition on every pk-column only once and one of this conditions should be < or > The reproducer is attached. was: The combination of these two conditions results in an empty selection always, but the result must not be empty. * Compound primary key (2 or more columns) * In select query in where clause use condition on every pk-column only once and one of this conditions should be < or > The reproducer is attached. > Incorrect work of predicates (< and >) in where clause with compound primary > key. > - > > Key: IGNITE-13765 > URL: https://issues.apache.org/jira/browse/IGNITE-13765 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ilya Kazakov >Priority: Major > Attachments: CompoundPkPredicateTest.java > > > The combination of these two conditions always gives an empty selection, but > the result must not be empty. > * Compound primary key (2 or more columns) > * In select query in where clause use condition on every pk-column only once > and one of this conditions should be < or > > The reproducer is attached. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13765) Incorrect work of predicates (< and >) in where clause with compound primary key.
[ https://issues.apache.org/jira/browse/IGNITE-13765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov updated IGNITE-13765: -- Description: The combination of these two conditions results in an empty selection always, but the result must not be empty. * Compound primary key (2 or more columns) * In select query in where clause use condition on every pk-column only once and one of this conditions should be < or > The reproducer is attached. was: Еhe combination of these two conditions results in an empty selection always, but the result must not be empty. * Compound primary key (2 or more columns) * In select query in where clause use condition on every pk-column only once and one of this conditions should be < or > The reproducer is attached. > Incorrect work of predicates (< and >) in where clause with compound primary > key. > - > > Key: IGNITE-13765 > URL: https://issues.apache.org/jira/browse/IGNITE-13765 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ilya Kazakov >Priority: Major > Attachments: CompoundPkPredicateTest.java > > > The combination of these two conditions results in an empty selection always, > but the result must not be empty. > * Compound primary key (2 or more columns) > * In select query in where clause use condition on every pk-column only once > and one of this conditions should be < or > > The reproducer is attached. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13765) Incorrect work of predicates (< and >) in where clause with compound primary key.
Ilya Kazakov created IGNITE-13765: - Summary: Incorrect work of predicates (< and >) in where clause with compound primary key. Key: IGNITE-13765 URL: https://issues.apache.org/jira/browse/IGNITE-13765 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.8.1, 2.9 Reporter: Ilya Kazakov Attachments: CompoundPkPredicateTest.java Еhe combination of these two conditions results in an empty selection always, but the result must not be empty. * Compound primary key (2 or more columns) * In select query in where clause use condition on every pk-column only once and one of this conditions should be < or > The reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13591) Add getLastCheckpointStarted metric
[ https://issues.apache.org/jira/browse/IGNITE-13591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224422#comment-17224422 ] Ilya Kazakov commented on IGNITE-13591: --- [~agura], I have implemented your instructions. Could I ask you review again, please? > Add getLastCheckpointStarted metric > --- > > Key: IGNITE-13591 > URL: https://issues.apache.org/jira/browse/IGNITE-13591 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Kazakov >Assignee: Ilya Kazakov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Sometimes one needs to understand how long ago did the last checkpoint start > or end, how long was it, etc. There is lastCheckpointDuration already - let’s > add lastCheckpointStarted timestamp. From these two metrics the user can also > figure out started + duration = ended and now - ended = time without cp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13630) Add a control.sh command to list running Continuous Queries
[ https://issues.apache.org/jira/browse/IGNITE-13630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov reassigned IGNITE-13630: - Assignee: Ilya Kazakov > Add a control.sh command to list running Continuous Queries > --- > > Key: IGNITE-13630 > URL: https://issues.apache.org/jira/browse/IGNITE-13630 > Project: Ignite > Issue Type: Sub-task >Reporter: Ilya Kazakov >Assignee: Ilya Kazakov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13629) Create a VisorTask for collecting running Continuous Queries
[ https://issues.apache.org/jira/browse/IGNITE-13629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221889#comment-17221889 ] Ilya Kazakov commented on IGNITE-13629: --- [~ilyak], please review > Create a VisorTask for collecting running Continuous Queries > > > Key: IGNITE-13629 > URL: https://issues.apache.org/jira/browse/IGNITE-13629 > Project: Ignite > Issue Type: Sub-task >Reporter: Ilya Kazakov >Assignee: Ilya Kazakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13630) Add a control.sh command to list running Continuous Queries
Ilya Kazakov created IGNITE-13630: - Summary: Add a control.sh command to list running Continuous Queries Key: IGNITE-13630 URL: https://issues.apache.org/jira/browse/IGNITE-13630 Project: Ignite Issue Type: Sub-task Reporter: Ilya Kazakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13629) Create a VisorTask for collecting running Continuous Queries
Ilya Kazakov created IGNITE-13629: - Summary: Create a VisorTask for collecting running Continuous Queries Key: IGNITE-13629 URL: https://issues.apache.org/jira/browse/IGNITE-13629 Project: Ignite Issue Type: Sub-task Reporter: Ilya Kazakov Assignee: Ilya Kazakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13628) Monitor the list of the currently running Continuous Queries
Ilya Kazakov created IGNITE-13628: - Summary: Monitor the list of the currently running Continuous Queries Key: IGNITE-13628 URL: https://issues.apache.org/jira/browse/IGNITE-13628 Project: Ignite Issue Type: Improvement Reporter: Ilya Kazakov Assignee: Ilya Kazakov Now, it's not possible to monitor the currently running CQs and their RemoteFilters. Let’s add interfaces to list all running CQs - via control.sh. Basic info we should extract is: * CQ ID * Listener node ID * Cache name * isLocal * localListener class name (or instance’s toString()?) * remoteFilter class name (or instance’s toString()?) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218252#comment-17218252
]
Ilya Kazakov commented on IGNITE-13028:
---
Ilya, check, please.
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-13028:
--
Release Note: Spring Data integration introspects the fields of the key
object (in case of using compound key) (was: If you using compound keys in
spring-data integration, you can omit query annotation and instead of such
method declaration:
@Query("SELECT * FROM City WHERE id = ?")
public Cache.Entry findById(int id);
use only:
public Cache.Entry findById(int id);)
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13398) NPE in IgniteServiceProcessor when destroying a cache
[
https://issues.apache.org/jira/browse/IGNITE-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov reassigned IGNITE-13398:
-
Assignee: Ilya Kazakov
> NPE in IgniteServiceProcessor when destroying a cache
> --
>
> Key: IGNITE-13398
> URL: https://issues.apache.org/jira/browse/IGNITE-13398
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Denis Mekhanikov
>Assignee: Ilya Kazakov
>Priority: Major
> Attachments: Main.java
>
>
> Try running the attached reproducer: [^Main.java]. The following exception is
> printed to the logs:
> {noformat}
> Sep 03, 2020 12:13:58 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to notify direct custom event listener:
> DynamicCacheChangeBatch [id=c1d6e335471-6bafb375-9d3e-487a-974d-35927ae02c04,
> reqs=ArrayList [DynamicCacheChangeRequest [cacheName=foo, hasCfg=false,
> nodeId=5e41fda8-e749-432c-9832-7b1c6ee3d0c8, clientStartOnly=false,
> stop=true, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=null, stopCaches=[foo],
> startGrps=[], stopGrps=[foo, destroy=true], resetParts=null,
> stateChangeRequest=null], startCaches=false]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.lambda$processDynamicCacheChangeRequest$6(IgniteServiceProcessor.java:1694)
> at java.util.Collection.removeIf(Collection.java:414)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.processDynamicCacheChangeRequest(IgniteServiceProcessor.java:1691)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.access$200(IgniteServiceProcessor.java:108)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:232)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:229)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:665)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:528)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2608)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2646)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13534) Using a Deprecated method and uninformative message in console
[
https://issues.apache.org/jira/browse/IGNITE-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217281#comment-17217281
]
Ilya Kazakov commented on IGNITE-13534:
---
[~ilyak] all your recommendations were taken into account
> Using a Deprecated method and uninformative message in console
> --
>
> Key: IGNITE-13534
> URL: https://issues.apache.org/jira/browse/IGNITE-13534
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When cluster started in INACTIVE status in console writes uninformative
> message:
> {code:java}
> >>> Ignite cluster is not active (limited functionality available). Use
> >>> control.(sh|bat) script or IgniteCluster interface to activate.{code}
> This message contains two words "active" and not contain word "state".
> From this message, users try use deprecated IgniteCluster.active(boolean
> active), but need to use IgniteCluster.state(ClusterState newState)
> Also there are 3 calls of this deprecated method IgniteCluster.active in
> IgniteKernal.class
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217234#comment-17217234
]
Ilya Kazakov commented on IGNITE-13028:
---
[~ilyak] please check my release note.
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-13028:
--
Release Note:
If you using compound keys in spring-data integration, you can omit query
annotation and instead of such method declaration:
@Query("SELECT * FROM City WHERE id = ?")
public Cache.Entry findById(int id);
use only:
public Cache.Entry findById(int id);
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13591) Add getLastCheckpointStarted metric
[ https://issues.apache.org/jira/browse/IGNITE-13591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kazakov reassigned IGNITE-13591: - Assignee: Ilya Kazakov > Add getLastCheckpointStarted metric > --- > > Key: IGNITE-13591 > URL: https://issues.apache.org/jira/browse/IGNITE-13591 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Kazakov >Assignee: Ilya Kazakov >Priority: Major > > Sometimes one needs to understand how long ago did the last checkpoint start > or end, how long was it, etc. There is lastCheckpointDuration already - let’s > add lastCheckpointStarted timestamp. From these two metrics the user can also > figure out started + duration = ended and now - ended = time without cp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13591) Add getLastCheckpointStarted metric
Ilya Kazakov created IGNITE-13591: - Summary: Add getLastCheckpointStarted metric Key: IGNITE-13591 URL: https://issues.apache.org/jira/browse/IGNITE-13591 Project: Ignite Issue Type: Improvement Reporter: Ilya Kazakov Sometimes one needs to understand how long ago did the last checkpoint start or end, how long was it, etc. There is lastCheckpointDuration already - let’s add lastCheckpointStarted timestamp. From these two metrics the user can also figure out started + duration = ended and now - ended = time without cp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215131#comment-17215131
]
Ilya Kazakov commented on IGNITE-13028:
---
[~ilyak], formatting fixes done
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214411#comment-17214411
]
Ilya Kazakov commented on IGNITE-13028:
---
[~ilyak], please review again.
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13534) Using a Deprecated method and uninformative message in console
[
https://issues.apache.org/jira/browse/IGNITE-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213816#comment-17213816
]
Ilya Kazakov commented on IGNITE-13534:
---
[~ilyak], please review
> Using a Deprecated method and uninformative message in console
> --
>
> Key: IGNITE-13534
> URL: https://issues.apache.org/jira/browse/IGNITE-13534
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cluster started in INACTIVE status in console writes uninformative
> message:
> {code:java}
> >>> Ignite cluster is not active (limited functionality available). Use
> >>> control.(sh|bat) script or IgniteCluster interface to activate.{code}
> This message contains two words "active" and not contain word "state".
> From this message, users try use deprecated IgniteCluster.active(boolean
> active), but need to use IgniteCluster.state(ClusterState newState)
> Also there are 3 calls of this deprecated method IgniteCluster.active in
> IgniteKernal.class
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13534) Using a Deprecated method and uninformative message in console
[
https://issues.apache.org/jira/browse/IGNITE-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212120#comment-17212120
]
Ilya Kazakov commented on IGNITE-13534:
---
PR: https://github.com/apache/ignite/pull/8347
> Using a Deprecated method and uninformative message in console
> --
>
> Key: IGNITE-13534
> URL: https://issues.apache.org/jira/browse/IGNITE-13534
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cluster started in INACTIVE status in console writes uninformative
> message:
> {code:java}
> >>> Ignite cluster is not active (limited functionality available). Use
> >>> control.(sh|bat) script or IgniteCluster interface to activate.{code}
> This message contains two words "active" and not contain word "state".
> From this message, users try use deprecated IgniteCluster.active(boolean
> active), but need to use IgniteCluster.state(ClusterState newState)
> Also there are 3 calls of this deprecated method IgniteCluster.active in
> IgniteKernal.class
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212089#comment-17212089
]
Ilya Kazakov commented on IGNITE-13028:
---
[~ilyak], hello! Please review!
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17210008#comment-17210008
]
Ilya Kazakov commented on IGNITE-13028:
---
https://github.com/apache/ignite/pull/8328
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13534) Using a Deprecated method and uninformative message in console
[
https://issues.apache.org/jira/browse/IGNITE-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-13534:
--
Fix Version/s: 2.10
> Using a Deprecated method and uninformative message in console
> --
>
> Key: IGNITE-13534
> URL: https://issues.apache.org/jira/browse/IGNITE-13534
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Fix For: 2.10
>
>
> When cluster started in INACTIVE status in console writes uninformative
> message:
> {code:java}
> >>> Ignite cluster is not active (limited functionality available). Use
> >>> control.(sh|bat) script or IgniteCluster interface to activate.{code}
> This message contains two words "active" and not contain word "state".
> From this message, users try use deprecated IgniteCluster.active(boolean
> active), but need to use IgniteCluster.state(ClusterState newState)
> Also there are 3 calls of this deprecated method IgniteCluster.active in
> IgniteKernal.class
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13534) Using a Deprecated method and uninformative message in console
[
https://issues.apache.org/jira/browse/IGNITE-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov reassigned IGNITE-13534:
-
Assignee: Ilya Kazakov
> Using a Deprecated method and uninformative message in console
> --
>
> Key: IGNITE-13534
> URL: https://issues.apache.org/jira/browse/IGNITE-13534
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
>
> When cluster started in INACTIVE status in console writes uninformative
> message:
> {code:java}
> >>> Ignite cluster is not active (limited functionality available). Use
> >>> control.(sh|bat) script or IgniteCluster interface to activate.{code}
> This message contains two words "active" and not contain word "state".
> From this message, users try use deprecated IgniteCluster.active(boolean
> active), but need to use IgniteCluster.state(ClusterState newState)
> Also there are 3 calls of this deprecated method IgniteCluster.active in
> IgniteKernal.class
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13534) Using a Deprecated method and uninformative message in console
Ilya Kazakov created IGNITE-13534:
-
Summary: Using a Deprecated method and uninformative message in
console
Key: IGNITE-13534
URL: https://issues.apache.org/jira/browse/IGNITE-13534
Project: Ignite
Issue Type: Improvement
Reporter: Ilya Kazakov
When cluster started in INACTIVE status in console writes uninformative message:
{code:java}
>>> Ignite cluster is not active (limited functionality available). Use
>>> control.(sh|bat) script or IgniteCluster interface to activate.{code}
This message contains two words "active" and not contain word "state".
>From this message, users try use deprecated IgniteCluster.active(boolean
>active), but need to use IgniteCluster.state(ClusterState newState)
Also there are 3 calls of this deprecated method IgniteCluster.active in
IgniteKernal.class
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208460#comment-17208460
]
Ilya Kazakov commented on IGNITE-13028:
---
I.
There are several questions about semantics of your proposal.
In your example we using composite key, which consists of *ID* and
*COUNTRYCODE* (but actually we know the *ID* field is unique, so you write a
query like this *"select * where id = ?"*).
But in general, if we write *findById( id)* method and have a composite key
in the repository, let's decide what semantic will be behind id. I see two
options:
# in the composite key look for all fields, which have the same type as an
argument in *findById( s)*, and generate the query using this fields.
# in the composite key look for an field with the name *ID*, and generate
query using this field.
Also, since we only use one field from the entire composite key, it would be
more correct to write that the *findById ( id)* method should return not one
value, but a collection, or the first one that comes across. Let's define the
semantics here too.
II.
About primitive types in keys. There is a method extended from CrudRepository.
For example in CountryRepository it is:
{code:java}
@Override public Optional findById(String s);{code}
Therefore we could not write:
{code:java}
public Cache.Entry findById(String s);{code}
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov reassigned IGNITE-13028:
-
Assignee: Ilya Kazakov
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
