[jira] [Commented] (IGNITE-14224) Extend logging of client failure handling.
[ https://issues.apache.org/jira/browse/IGNITE-14224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302265#comment-17302265 ] Vladimir Goncharov commented on IGNITE-14224: - Java 1.8.251/241 Oracle/Open W/o fix - exception on spi.openSocket in ServerImpl.sendMessageDirectly. IgniteSpiException : class org.apache.ignite.spi.IgniteSpiException: Failed to send message to address [addr=/127.0.0.1:47500, msg=TcpDiscoveryJoinRequestMessage [node=TcpDiscoveryNode [id=b712cdf2-5e80-4d05-b45c-a113bdeea34b, consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501], discPort=47501, order=0, intOrder=0, lastExchangeTime=1615819551929, loc=true, ver=2.11.0#20210310-sha1:e90f9666, isClient=false], dataPacket=org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket@33a630fa, super=TcpDiscoveryAbstractMessage [sndNodeId=null, id=3ec89563871-b712cdf2-5e80-4d05-b45c-a113bdeea34b, verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, isClient=false]]] Connection count doesnt increment and spi.joinTimeout is zero. This leads to infintite cycle of cluster joining. With fix - timeout exception after open socket and sending message as expected witch correct stopping of joining node after 3 failed connection. Got exception while starting (will rollback startup routine). Command protocol successfully stopped: TCP binary Java 1.8.261/271/281 Oracle/Open Works with and without patch as well > Extend logging of client failure handling. > -- > > Key: IGNITE-14224 > URL: https://issues.apache.org/jira/browse/IGNITE-14224 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 2.9.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > # "Finished serving remote node connection " but this message doesn't contain > node id, it should be added (check > org.apache.ignite.spi.discovery.tcp.ServerImpl.SocketReader#body). > # When client worker is removed from clientMsgWorkers, > org.apache.ignite.internal.util.IgniteUtils#closeQuiet(java.lang.AutoCloseable) > is used to close the socket, we don't see any exception if it has happened, > closeQuiet should be replaced with > org.apache.ignite.internal.util.IgniteUtils#close(java.lang.AutoCloseable, > org.apache.ignite.IgniteLogger) which works in the same way but prints > exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14224) Extend logging of client failure handling.
[ https://issues.apache.org/jira/browse/IGNITE-14224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302296#comment-17302296 ] Pavel Tupitsyn commented on IGNITE-14224: - [~zstan] looks good to me, thanks! > Extend logging of client failure handling. > -- > > Key: IGNITE-14224 > URL: https://issues.apache.org/jira/browse/IGNITE-14224 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 2.9.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > # "Finished serving remote node connection " but this message doesn't contain > node id, it should be added (check > org.apache.ignite.spi.discovery.tcp.ServerImpl.SocketReader#body). > # When client worker is removed from clientMsgWorkers, > org.apache.ignite.internal.util.IgniteUtils#closeQuiet(java.lang.AutoCloseable) > is used to close the socket, we don't see any exception if it has happened, > closeQuiet should be replaced with > org.apache.ignite.internal.util.IgniteUtils#close(java.lang.AutoCloseable, > org.apache.ignite.IgniteLogger) which works in the same way but prints > exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[
https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302330#comment-17302330
]
Anton Vinogradov commented on IGNITE-14228:
---
[~cyberdemon], [~nizhikov] thanks for your contribution, but I'd like to
mention some tips related to the merged code.
1) Some code does nothing but enlarges PR/file size.
For example,
{noformat}
if (n >= MAX_STREAMER_DATA_SIZE) {
n = 0;
stmr.flush();
}
{noformat}
provides no real value, but takes 8 lines with const definition.
2) Some code makes some ... overcomplicated magic, at least for the reader who
faces it the first time.
{{int logStreamedEntriesQuant = (int)Math.pow(10, (int)Math.log10(entryCnt) -
1);}}
Do we really need such calculations for logging? Why not just {{if i % z == 0
...}} ?
3) In case you have custom await logic you must make it strict
{noformat}
app, app.nodes[0], "Marking as initialized") - get_event_time(
app, app.nodes[0], "Data generation started")).total_seconds()
{noformat}
Here, you invented the {{Data generation started}} event, and it will be much
better if you'd also invent the {{finished}} event, this would make core
refactoring friendly.
4) Exception should never be hidden
{noformat}
for node in ignite.nodes:
try:
rebalance_start_time = get_event_time(
ignite, node,
"Starting rebalance routine \\[test-cache-",
timeout=timeout)
except TimeoutError:
continue
else:
return {"node": node, "time": rebalance_start_time}
{noformat}
Once you got an Exception you must handle it, not pass.
5) Your code should always be as simple as possible,
for example, following
{noformat}
for cache_idx in range(cache_count):
rebalance_complete_times.append(get_event_time(
ignite,
node if node else ignite.nodes[0],
"Completed rebalance future: RebalanceFuture \\[%s
\\[grp=test-cache-%d" %
("state=STARTED, grp=CacheGroupContext", cache_idx + 1),
timeout=timeout))
return max(rebalance_complete_times)
{noformat}
can be replaced with just one line
{noformat}
get_event_time(..., "Completed rebalance (final)", ...)
{noformat}
6) Newer build a Wunderwaffe
At the following code, you never need {{node}} and {{time}} as dictionary
indices,
{noformat}
start_node_and_time = await_rebalance_start(ignite)
complete_time = await_rebalance_complete(ignite, start_node_and_time["node"],
cache_count)
return {"Rebalanced in (sec)": (complete_time -
start_node_and_time["time"]).total_seconds(),
{noformat}
all you need here is to return tupple instead.
> Ducktape test of rebalance for in-memory mode
> -
>
> Key: IGNITE-14228
> URL: https://issues.apache.org/jira/browse/IGNITE-14228
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> This test should check the rebalance on in-memory caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology.
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> expected that greater value makes rebalance faster on large data or
> [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
> enabled (rebalanceThrottling > 0).
> # Rebalance throttle - the value for
> {{IgniteConfiguration#rebalanceThrottle}} property (see [rebalance message
> throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
> [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> 0 - throttling disabled, greater value makes rebalance slower.
> Test result: time taken to rebalance process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[
https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302330#comment-17302330
]
Anton Vinogradov edited comment on IGNITE-14228 at 3/16/21, 9:07 AM:
-
[~cyberdemon], [~nizhikov] thanks for your contribution, but I'd like to
mention some tips related to the merged code.
1) Some code does nothing but enlarges PR/file size.
For example,
{noformat}
if (n >= MAX_STREAMER_DATA_SIZE) {
n = 0;
stmr.flush();
}
{noformat}
provides no real value, but takes 8 lines with const definition.
2) Some code makes some ... overcomplicated magic, at least for the reader who
faces it the first time.
{{int logStreamedEntriesQuant = (int)Math.pow(10, (int)Math.log10(entryCnt) -
1);}}
Do we really need such calculations for logging? Why not just {{if i % z == 0
...}} ?
3) In case you have custom await logic you must make it strict
{noformat}
app, app.nodes[0], "Marking as initialized") - get_event_time(
app, app.nodes[0], "Data generation started")).total_seconds()
{noformat}
Here, you invented the {{Data generation started}} event, and it will be much
better if you'd also invent the {{finished}} event, this would make core
refactoring friendly.
4) Exception should never be hidden
{noformat}
for node in ignite.nodes:
try:
rebalance_start_time = get_event_time(
ignite, node,
"Starting rebalance routine \\[test-cache-",
timeout=timeout)
except TimeoutError:
continue
else:
return {"node": node, "time": rebalance_start_time}
{noformat}
Once you got an Exception you must handle it, not pass.
5) Your code should always be as simple as possible,
for example, following
{noformat}
for cache_idx in range(cache_count):
rebalance_complete_times.append(get_event_time(
ignite,
node if node else ignite.nodes[0],
"Completed rebalance future: RebalanceFuture \\[%s
\\[grp=test-cache-%d" %
("state=STARTED, grp=CacheGroupContext", cache_idx + 1),
timeout=timeout))
return max(rebalance_complete_times)
{noformat}
can be replaced with just one line
{noformat}
get_event_time(..., "Completed rebalance (final)", ...)
{noformat}
6) Never build a Wunderwaffe
At the following code, you never need {{node}} and {{time}} as dictionary
indices,
{noformat}
start_node_and_time = await_rebalance_start(ignite)
complete_time = await_rebalance_complete(ignite, start_node_and_time["node"],
cache_count)
return {"Rebalanced in (sec)": (complete_time -
start_node_and_time["time"]).total_seconds(),
{noformat}
all you need here is to return tupple instead.
was (Author: av):
[~cyberdemon], [~nizhikov] thanks for your contribution, but I'd like to
mention some tips related to the merged code.
1) Some code does nothing but enlarges PR/file size.
For example,
{noformat}
if (n >= MAX_STREAMER_DATA_SIZE) {
n = 0;
stmr.flush();
}
{noformat}
provides no real value, but takes 8 lines with const definition.
2) Some code makes some ... overcomplicated magic, at least for the reader who
faces it the first time.
{{int logStreamedEntriesQuant = (int)Math.pow(10, (int)Math.log10(entryCnt) -
1);}}
Do we really need such calculations for logging? Why not just {{if i % z == 0
...}} ?
3) In case you have custom await logic you must make it strict
{noformat}
app, app.nodes[0], "Marking as initialized") - get_event_time(
app, app.nodes[0], "Data generation started")).total_seconds()
{noformat}
Here, you invented the {{Data generation started}} event, and it will be much
better if you'd also invent the {{finished}} event, this would make core
refactoring friendly.
4) Exception should never be hidden
{noformat}
for node in ignite.nodes:
try:
rebalance_start_time = get_event_time(
ignite, node,
"Starting rebalance routine \\[test-cache-",
timeout=timeout)
except TimeoutError:
continue
else:
return {"node": node, "time": rebalance_start_time}
{noformat}
Once you got an Exception you must handle it, not pass.
5) Your code should always be as simple as possible,
for example, following
{noformat}
for cache_idx in range(cache_count):
rebalance_complete_times.append(get_event_time(
ignite,
node if node else ignite.nodes[0],
"Completed rebalance future: RebalanceFuture \\[%s
\\[grp=test-cache-%d" %
("state=STARTED, grp=CacheGroupContext", cache_idx + 1),
timeout=timeout))
return max(rebalance_complete_times)
{noformat}
can be replaced with just one line
{noformat}
get_event_time(..., "Completed rebalance (final)", ...)
{noformat}
6) Newer build a Wunderwaffe
At the following code, you never need {{n
[jira] [Updated] (IGNITE-14224) Extend logging of client failure handling.
[ https://issues.apache.org/jira/browse/IGNITE-14224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14224: - Fix Version/s: 2.11 > Extend logging of client failure handling. > -- > > Key: IGNITE-14224 > URL: https://issues.apache.org/jira/browse/IGNITE-14224 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 2.9.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.11 > > Time Spent: 1h > Remaining Estimate: 0h > > # "Finished serving remote node connection " but this message doesn't contain > node id, it should be added (check > org.apache.ignite.spi.discovery.tcp.ServerImpl.SocketReader#body). > # When client worker is removed from clientMsgWorkers, > org.apache.ignite.internal.util.IgniteUtils#closeQuiet(java.lang.AutoCloseable) > is used to close the socket, we don't see any exception if it has happened, > closeQuiet should be replaced with > org.apache.ignite.internal.util.IgniteUtils#close(java.lang.AutoCloseable, > org.apache.ignite.IgniteLogger) which works in the same way but prints > exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14224) Extend logging of client failure handling.
[ https://issues.apache.org/jira/browse/IGNITE-14224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302351#comment-17302351 ] Sergey Chugunov commented on IGNITE-14224: -- [~zstan], Patch looks good to me as well, I merged it to master branch in commit *8e154f0d7eee5825c82e6158f3dac725d7bfe847*. Thank you for contribution! > Extend logging of client failure handling. > -- > > Key: IGNITE-14224 > URL: https://issues.apache.org/jira/browse/IGNITE-14224 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 2.9.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.11 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > # "Finished serving remote node connection " but this message doesn't contain > node id, it should be added (check > org.apache.ignite.spi.discovery.tcp.ServerImpl.SocketReader#body). > # When client worker is removed from clientMsgWorkers, > org.apache.ignite.internal.util.IgniteUtils#closeQuiet(java.lang.AutoCloseable) > is used to close the socket, we don't see any exception if it has happened, > closeQuiet should be replaced with > org.apache.ignite.internal.util.IgniteUtils#close(java.lang.AutoCloseable, > org.apache.ignite.IgniteLogger) which works in the same way but prints > exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
Aleksandr Polovtcev created IGNITE-14322: Summary: False warning about DataRegionConfiguration.maxWalArchiveSize property usage Key: IGNITE-14322 URL: https://issues.apache.org/jira/browse/IGNITE-14322 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev On every non-persistent startup the following is printed: DataRegionConfiguration.maxWalArchiveSize instead DataRegionConfiguration.walHistorySize would be used for removing old archive wal files This does not make sense when persistence is totally off. Also, syntax should be fixed, "instead of", should be more clear what's going on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14224) Extend logging of client failure handling.
[ https://issues.apache.org/jira/browse/IGNITE-14224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-14224: Release Note: Additional logging helps to find root cause in case of client node failure but server nodes can`t detect it. > Extend logging of client failure handling. > -- > > Key: IGNITE-14224 > URL: https://issues.apache.org/jira/browse/IGNITE-14224 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 2.9.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.11 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > # "Finished serving remote node connection " but this message doesn't contain > node id, it should be added (check > org.apache.ignite.spi.discovery.tcp.ServerImpl.SocketReader#body). > # When client worker is removed from clientMsgWorkers, > org.apache.ignite.internal.util.IgniteUtils#closeQuiet(java.lang.AutoCloseable) > is used to close the socket, we don't see any exception if it has happened, > closeQuiet should be replaced with > org.apache.ignite.internal.util.IgniteUtils#close(java.lang.AutoCloseable, > org.apache.ignite.IgniteLogger) which works in the same way but prints > exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14295) Message interface to be introduced
[ https://issues.apache.org/jira/browse/IGNITE-14295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14295: - Description: Network module should introduce a public Message interface to handle messages to send and receive. This interface should provide at least information about message type (and possible version) to enable effective serialization/deserialization and ability to subscribe for a messages of certain type. API clarifications: # Message should not be responsible for reading itself from and writing to a byte buffer. Some kind of builder/converted has to be introduced. # We need a factory for instantiating Message objects or builders/converters for these objects by message type. # We need a requirement for components workflow so components can register their message types in network component and make sure there are no conflicts between them. was: Network module should introduce a public Message interface to handle messages to send and receive. This interface should provide at least information about message type (and possible version) to enable effective serialization/deserialization and ability to subscribe for a messages of certain type. > Message interface to be introduced > -- > > Key: IGNITE-14295 > URL: https://issues.apache.org/jira/browse/IGNITE-14295 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Priority: Major > Fix For: 3.0.0-alpha2 > > > Network module should introduce a public Message interface to handle messages > to send and receive. > This interface should provide at least information about message type (and > possible version) to enable effective serialization/deserialization and > ability to subscribe for a messages of certain type. > API clarifications: > # Message should not be responsible for reading itself from and writing to a > byte buffer. Some kind of builder/converted has to be introduced. > # We need a factory for instantiating Message objects or builders/converters > for these objects by message type. > # We need a requirement for components workflow so components can register > their message types in network component and make sure there are no conflicts > between them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[ https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14322: - Fix Version/s: 2.11 > False warning about DataRegionConfiguration.maxWalArchiveSize property usage > > > Key: IGNITE-14322 > URL: https://issues.apache.org/jira/browse/IGNITE-14322 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > > On every non-persistent startup the following is printed: > DataRegionConfiguration.maxWalArchiveSize instead > DataRegionConfiguration.walHistorySize would be used for removing old archive > wal files > This does not make sense when persistence is totally off. > Also, syntax should be fixed, "instead of", should be more clear what's going > on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[ https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14322: - Affects Version/s: 2.10 > False warning about DataRegionConfiguration.maxWalArchiveSize property usage > > > Key: IGNITE-14322 > URL: https://issues.apache.org/jira/browse/IGNITE-14322 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > > On every non-persistent startup the following is printed: > DataRegionConfiguration.maxWalArchiveSize instead > DataRegionConfiguration.walHistorySize would be used for removing old archive > wal files > This does not make sense when persistence is totally off. > Also, syntax should be fixed, "instead of", should be more clear what's going > on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[ https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14322: - Component/s: persistence > False warning about DataRegionConfiguration.maxWalArchiveSize property usage > > > Key: IGNITE-14322 > URL: https://issues.apache.org/jira/browse/IGNITE-14322 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > > On every non-persistent startup the following is printed: > DataRegionConfiguration.maxWalArchiveSize instead > DataRegionConfiguration.walHistorySize would be used for removing old archive > wal files > This does not make sense when persistence is totally off. > Also, syntax should be fixed, "instead of", should be more clear what's going > on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14323) Messaging naming unification
Sergey Chugunov created IGNITE-14323: Summary: Messaging naming unification Key: IGNITE-14323 URL: https://issues.apache.org/jira/browse/IGNITE-14323 Project: Ignite Issue Type: Sub-task Components: networking Reporter: Sergey Chugunov Fix For: 3.0.0-alpha2 Naming of methods for message sending in NetworkCluster interface could be unified. # *send* method returning CompletableFuture with semantics "send message and wait when remote node replies with result". # *sendNoAck* method returning void with semantics "send message to remote node and returns immediately when message is sent to it (written to output connection)" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14323) Messaging naming unification
[ https://issues.apache.org/jira/browse/IGNITE-14323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14323: - Ignite Flags: (was: Docs Required,Release Notes Required) > Messaging naming unification > > > Key: IGNITE-14323 > URL: https://issues.apache.org/jira/browse/IGNITE-14323 > Project: Ignite > Issue Type: Sub-task > Components: networking >Reporter: Sergey Chugunov >Priority: Minor > Fix For: 3.0.0-alpha2 > > > Naming of methods for message sending in NetworkCluster interface could be > unified. > # *send* method returning CompletableFuture with semantics "send message and > wait when remote node replies with result". > # *sendNoAck* method returning void with semantics "send message to remote > node and returns immediately when message is sent to it (written to output > connection)" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14224) Extend logging of client failure handling.
[ https://issues.apache.org/jira/browse/IGNITE-14224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302265#comment-17302265 ] Vladimir Goncharov edited comment on IGNITE-14224 at 3/16/21, 11:25 AM: W10 HOME/PRO JDK1.8.251/241 Oracle/Open W/o fix - exception on spi.openSocket in ServerImpl.sendMessageDirectly. IgniteSpiException : class org.apache.ignite.spi.IgniteSpiException: Failed to send message to address [addr=/127.0.0.1:47500, msg=TcpDiscoveryJoinRequestMessage [node=TcpDiscoveryNode [id=b712cdf2-5e80-4d05-b45c-a113bdeea34b, consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501], discPort=47501, order=0, intOrder=0, lastExchangeTime=1615819551929, loc=true, ver=2.11.0#20210310-sha1:e90f9666, isClient=false], dataPacket=org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket@33a630fa, super=TcpDiscoveryAbstractMessage [sndNodeId=null, id=3ec89563871-b712cdf2-5e80-4d05-b45c-a113bdeea34b, verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, isClient=false]]] Connection count doesnt increment and spi.joinTimeout is zero. This leads to infintite cycle of cluster joining. With fix - timeout exception after open socket and sending message as expected witch correct stopping of joining node after 3 failed connection. Got exception while starting (will rollback startup routine). Command protocol successfully stopped: TCP binary JDK 1.8.261/271/281 Oracle/Open Works with and without patch as well was (Author: shadowru): Java 1.8.251/241 Oracle/Open W/o fix - exception on spi.openSocket in ServerImpl.sendMessageDirectly. IgniteSpiException : class org.apache.ignite.spi.IgniteSpiException: Failed to send message to address [addr=/127.0.0.1:47500, msg=TcpDiscoveryJoinRequestMessage [node=TcpDiscoveryNode [id=b712cdf2-5e80-4d05-b45c-a113bdeea34b, consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501], discPort=47501, order=0, intOrder=0, lastExchangeTime=1615819551929, loc=true, ver=2.11.0#20210310-sha1:e90f9666, isClient=false], dataPacket=org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket@33a630fa, super=TcpDiscoveryAbstractMessage [sndNodeId=null, id=3ec89563871-b712cdf2-5e80-4d05-b45c-a113bdeea34b, verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, isClient=false]]] Connection count doesnt increment and spi.joinTimeout is zero. This leads to infintite cycle of cluster joining. With fix - timeout exception after open socket and sending message as expected witch correct stopping of joining node after 3 failed connection. Got exception while starting (will rollback startup routine). Command protocol successfully stopped: TCP binary Java 1.8.261/271/281 Oracle/Open Works with and without patch as well > Extend logging of client failure handling. > -- > > Key: IGNITE-14224 > URL: https://issues.apache.org/jira/browse/IGNITE-14224 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 2.9.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.11 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > # "Finished serving remote node connection " but this message doesn't contain > node id, it should be added (check > org.apache.ignite.spi.discovery.tcp.ServerImpl.SocketReader#body). > # When client worker is removed from clientMsgWorkers, > org.apache.ignite.internal.util.IgniteUtils#closeQuiet(java.lang.AutoCloseable) > is used to close the socket, we don't see any exception if it has happened, > closeQuiet should be replaced with > org.apache.ignite.internal.util.IgniteUtils#close(java.lang.AutoCloseable, > org.apache.ignite.IgniteLogger) which works in the same way but prints > exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14324) EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s
Alexandr Shapkin created IGNITE-14324: - Summary: EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s Key: IGNITE-14324 URL: https://issues.apache.org/jira/browse/IGNITE-14324 Project: Ignite Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.11 Scenario: Kubernetes world, a server node, a k8s service, and a thick client. The client is subscribed to EVT_CLIENT_NODE_DISCONNECTED event and is connected to the server node. When a service goes down alongside the server, no EVT_CLIENT_NODE_DISCONNECTED is caught and the client reports only about a socket exception and inability to resolve IP addresses from the services, cause k8s resource is not available. The DEBUG logs (attached) show that discovery is constantly trying to use KubernetesIpFinder and restore the connection. Expected: Discovery realizes that a client is disconnected, no more reconnection attempts happen and EVT_CLIENT_NODE_DISCONNECTED is thrown. Solution: Count resolution attempts and if it’s more than the threshold (2 if failuredetectiontimeout is not configured, otherwise #reconnCount) give up and invoke disconnection logic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14305) Snapshot check command for indexed cache ends with exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302476#comment-17302476
]
Ignite TC Bot commented on IGNITE-14305:
{panel:title=Branch: [pull/8874/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8874/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5914903]]
* {color:#013220}IgnitePdsWithIndexingTestSuite:
IgniteClusterSnapshotCheckWithIndexesTest.testClusterSnapshotCheckWithIndexes -
PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
IgniteClusterSnapshotCheckWithIndexesTest.testClusterSnapshotCheckEmptyCache -
PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
IgniteClusterSnapshotCheckWithIndexesTest.testClusterSnapshotCheckWithNodeFilter
- PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5914936&buildTypeId=IgniteTests24Java8_RunAll]
> Snapshot check command for indexed cache ends with exceptions
> -
>
> Key: IGNITE-14305
> URL: https://issues.apache.org/jira/browse/IGNITE-14305
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.11
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The snapshot validation command reports exceptions when executed on a
> snapshot containing cache with SQL-indexes.
> Reproducer
> {code:java}
> import org.apache.ignite.cache.QueryEntity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.processors.cache.verify.IdleVerifyResultV2;
> import org.apache.ignite.internal.util.typedef.F;
> import org.junit.Test;
> import static java.util.Collections.singletonList;
> public class IgniteClusterSnapshotCheckWithIndexesTest extends
> AbstractSnapshotSelfTest {
> private final CacheConfiguration indexedCcfg =
> txCacheConfig(new CacheConfiguration("indexed"))
> .setQueryEntities(singletonList(new
> QueryEntity(Integer.class.getName(), Account.class.getName(;
> @Test
> public void testClusterSnapshotCheckWithIndexes() throws Exception {
> IgniteEx ignite = startGridsWithCache(3, CACHE_KEYS_RANGE, key -> new
> Account(key, key), indexedCcfg);
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get();
> IdleVerifyResultV2 res =
> ignite.context().cache().context().snapshotMgr().checkSnapshot(SNAPSHOT_NAME).get();
> if (!F.isEmpty(res.exceptions())) {
> StringBuilder sb = new StringBuilder();
> res.print(sb::append, true);
> fail(sb.toString());
> }
> }
> }
> {code}
>
> Stderr output
> {noformat}
> java.lang.AssertionError: The check procedure failed on 3 nodes.
> The check procedure has finished, no conflicts have been found.
> The check procedure failed on nodes:
> Node ID: 1db72a3a-a1d8-48d7-9d25-96769312 [127.0.0.1]
> Consistent ID: snapshot.IgniteClusterSnapshotCheckWithIndexesTest2
> Exception: org.apache.ignite.IgniteException
> Snapshot data doesn't contain required cache group partition
> [grpId=1943292145, snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest2, missed=[65535],
> meta=SnapshotMetadata [rqId=7d5af20a-3247-41b4-a2d6-ed50bb63b249,
> snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest2,
> folderName=snapshot_IgniteClusterSnapshotCheckWithIndexesTest2,
> pageSize=4096, grpIds=ArrayList [1943292145], bltNodes=HashSet
> [snapshot.IgniteClusterSnapshotCheckWithIndexesTest2,
> snapshot.IgniteClusterSnapshotCheckWithIndexesTest1,
> snapshot.IgniteClusterSnapshotCheckWithIndexesTest0], locParts=HashMap
> {1943292145=HashSet [0, 1, 2, 3, 4, 5, 6, 7, 65535]}]]
> Node ID: e49c924f-3fae-40ca-bb7c-c6905281 [127.0.0.1]
> Consistent ID: snapshot.IgniteClusterSnapshotCheckWithIndexesTest1
> Exception: org.apache.ignite.IgniteException
> Snapshot data doesn't contain required cache group partition
> [grpId=1943292145, snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest1, missed=[65535],
> meta=SnapshotMetadata [rqId=7d5af20a-3247-41b4-a2d6-ed50bb63b249,
> snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest1,
> folderName=snapshot_IgniteClusterSnapshotCheckWithIndexesTest1,
> pageSize=4096, grpIds=ArrayList [1943292145], bltNodes=HashSet
> [snapshot.IgniteClusterSnapshotCheckWithIndexesTest2,
> snapshot.Ig
[jira] [Commented] (IGNITE-8635) Add a method to inspect BinaryObject size
[
https://issues.apache.org/jira/browse/IGNITE-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302484#comment-17302484
]
Ignite TC Bot commented on IGNITE-8635:
---
{panel:title=Branch: [pull/8868/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5914370]]
{panel}
{panel:title=Branch: [pull/8868/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5914403&buildTypeId=IgniteTests24Java8_RunAll]
> Add a method to inspect BinaryObject size
> -
>
> Key: IGNITE-8635
> URL: https://issues.apache.org/jira/browse/IGNITE-8635
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently only concrete implementations of {{BinaryObject}} interface provide
> some information regarding the object serialized size. It makes it hard for
> users to reason about storage size and estimate required storage capacity.
> We need to add a method to the {{BinaryObject}} interface itself to return
> the actual size required to store the object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8635) Add a method to inspect BinaryObject size
[
https://issues.apache.org/jira/browse/IGNITE-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-8635:
Component/s: binary
> Add a method to inspect BinaryObject size
> -
>
> Key: IGNITE-8635
> URL: https://issues.apache.org/jira/browse/IGNITE-8635
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Reporter: Alexey Goncharuk
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently only concrete implementations of {{BinaryObject}} interface provide
> some information regarding the object serialized size. It makes it hard for
> users to reason about storage size and estimate required storage capacity.
> We need to add a method to the {{BinaryObject}} interface itself to return
> the actual size required to store the object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-8635) Add a method to inspect BinaryObject size
[
https://issues.apache.org/jira/browse/IGNITE-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev resolved IGNITE-8635.
-
Fix Version/s: 2.11
Release Note: Added size() method to BinaryObject interface.
Resolution: Fixed
Thank you for the contribution [~atri], I have merged it to master after CC
tweaks.
> Add a method to inspect BinaryObject size
> -
>
> Key: IGNITE-8635
> URL: https://issues.apache.org/jira/browse/IGNITE-8635
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently only concrete implementations of {{BinaryObject}} interface provide
> some information regarding the object serialized size. It makes it hard for
> users to reason about storage size and estimate required storage capacity.
> We need to add a method to the {{BinaryObject}} interface itself to return
> the actual size required to store the object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14281) Calcite. Colocated tables are considered non colocated
[ https://issues.apache.org/jira/browse/IGNITE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302488#comment-17302488 ] Konstantin Orlov commented on IGNITE-14281: --- [~tledkov-gridgain], [~zstan], folks, could you please do a review > Calcite. Colocated tables are considered non colocated > -- > > Key: IGNITE-14281 > URL: https://issues.apache.org/jira/browse/IGNITE-14281 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently distribution trait for replicated cache is built over 0th column > which is _KEY column. Because of this a colocated join is considered > non-colocated until _KEY columns is not used explicitly as join predicate. > Need to fix this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14320) .NET: Collections can't be used as service method parameters
[
https://issues.apache.org/jira/browse/IGNITE-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302493#comment-17302493
]
Pavel Tupitsyn commented on IGNITE-14320:
-
[~nizhikov] looks good to me, thanks for catching this.
> .NET: Collections can't be used as service method parameters
>
>
> Key: IGNITE-14320
> URL: https://issues.apache.org/jira/browse/IGNITE-14320
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, collections (list, map) can't be used as a service method
> parameter in case of
> .Net (client node) -> .Net (server node) call.
> This can be reproduced my one line modification of
> {{ServicesTypeAutoResolveTest#DoTestPlatformService}}
> {code:java}
> ///
> /// Tests .Net service invocation.
> ///
> public void DoTestPlatformService(IServices svcsForProxy)
> {
> const string platformSvcName = "PlatformTestService";
> _grid1.GetServices().DeployClusterSingleton(platformSvcName, new
> PlatformTestService());
> var svc =
> svcsForProxy.GetServiceProxy(platformSvcName);
> DoTestService(svc);
> DoTestCollections(svc); // This line was added.
> _grid1.GetServices().Cancel(platformSvcName);
> }
> {code}
> Exception:
> {noformat}
> Apache.Ignite.Core.Services.ServiceInvocationException : Proxy method
> invocation failed with an exception. Examine InnerException for details.
> > Apache.Ignite.Core.Common.IgniteException : No matching type found
> for object [typeId=1552553483,
> typeName=org.system.collections.generic.List`1[[org.apache.ignite.platform.model.department,
> apache.ignite.core.testDepartment]]]. This usually indicates that assembly
> with specified type is not loaded on a node. When using Apache.Ignite.exe,
> make sure to load assemblies with -assembly parameter. Alternatively, set
> IgniteConfiguration.PeerAssemblyLoadingMode to CurrentAppDomain.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14295) Message interface to be introduced
[ https://issues.apache.org/jira/browse/IGNITE-14295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov reassigned IGNITE-14295: --- Assignee: Semyon Danilov > Message interface to be introduced > -- > > Key: IGNITE-14295 > URL: https://issues.apache.org/jira/browse/IGNITE-14295 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Fix For: 3.0.0-alpha2 > > > Network module should introduce a public Message interface to handle messages > to send and receive. > This interface should provide at least information about message type (and > possible version) to enable effective serialization/deserialization and > ability to subscribe for a messages of certain type. > API clarifications: > # Message should not be responsible for reading itself from and writing to a > byte buffer. Some kind of builder/converted has to be introduced. > # We need a factory for instantiating Message objects or builders/converters > for these objects by message type. > # We need a requirement for components workflow so components can register > their message types in network component and make sure there are no conflicts > between them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14320) .NET: Collections can't be used as service method parameters
[
https://issues.apache.org/jira/browse/IGNITE-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302557#comment-17302557
]
Nikolay Izhikov commented on IGNITE-14320:
--
https://ci.ignite.apache.org/viewLog.html?buildId=5917633 - tests
> .NET: Collections can't be used as service method parameters
>
>
> Key: IGNITE-14320
> URL: https://issues.apache.org/jira/browse/IGNITE-14320
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, collections (list, map) can't be used as a service method
> parameter in case of
> .Net (client node) -> .Net (server node) call.
> This can be reproduced my one line modification of
> {{ServicesTypeAutoResolveTest#DoTestPlatformService}}
> {code:java}
> ///
> /// Tests .Net service invocation.
> ///
> public void DoTestPlatformService(IServices svcsForProxy)
> {
> const string platformSvcName = "PlatformTestService";
> _grid1.GetServices().DeployClusterSingleton(platformSvcName, new
> PlatformTestService());
> var svc =
> svcsForProxy.GetServiceProxy(platformSvcName);
> DoTestService(svc);
> DoTestCollections(svc); // This line was added.
> _grid1.GetServices().Cancel(platformSvcName);
> }
> {code}
> Exception:
> {noformat}
> Apache.Ignite.Core.Services.ServiceInvocationException : Proxy method
> invocation failed with an exception. Examine InnerException for details.
> > Apache.Ignite.Core.Common.IgniteException : No matching type found
> for object [typeId=1552553483,
> typeName=org.system.collections.generic.List`1[[org.apache.ignite.platform.model.department,
> apache.ignite.core.testDepartment]]]. This usually indicates that assembly
> with specified type is not loaded on a node. When using Apache.Ignite.exe,
> make sure to load assemblies with -assembly parameter. Alternatively, set
> IgniteConfiguration.PeerAssemblyLoadingMode to CurrentAppDomain.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-14076:
Issue Type: Improvement (was: Bug)
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14325) SQL COPY command: when conversion fails, the error does not contain information about line number and the failed value
Alexey Goncharuk created IGNITE-14325:
-
Summary: SQL COPY command: when conversion fails, the error does
not contain information about line number and the failed value
Key: IGNITE-14325
URL: https://issues.apache.org/jira/browse/IGNITE-14325
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.10
Reporter: Alexey Goncharuk
I was trying to import data from a CSV file to Ignite cache through sqlline.
When a file contains a value that cannot be converted to the schema format, the
error message printed by the client is absolutely useless:
{code}
Error: Server error: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Value
conversion failed [column=PICKUP_DATETIME, from=java.lang.String,
to=java.sql.Timestamp] (state=5,code=1)
java.sql.SQLException: Server error: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Value
conversion failed [column=PICKUP_DATETIME, from=java.lang.String,
to=java.sql.Timestamp]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.sendFile(JdbcThinStatement.java:336)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:243)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
at sqlline.Commands.executeSingleQuery(Commands.java:1054)
at sqlline.Commands.execute(Commands.java:1003)
at sqlline.Commands.sql(Commands.java:967)
at sqlline.SqlLine.dispatch(SqlLine.java:734)
at sqlline.SqlLine.begin(SqlLine.java:541)
at sqlline.SqlLine.start(SqlLine.java:267)
at sqlline.SqlLine.main(SqlLine.java:206)
{code}
The server log does not contain any helpful information as well.
When input validation failed, we need to output the following context
information:
* Line number of the source file that triggered the error
* A few values preceding the wrong column
* The exact value that failed parse/conversion error
* For complex types (such as date/timestamp), the acceptable input formats
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14274) Calcite integration: refactoring aggregates converter rules: single and map/reduce
[ https://issues.apache.org/jira/browse/IGNITE-14274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302658#comment-17302658 ] Konstantin Orlov commented on IGNITE-14274: --- [~tledkov-gridgain], the patch looks good to me > Calcite integration: refactoring aggregates converter rules: single and > map/reduce > -- > > Key: IGNITE-14274 > URL: https://issues.apache.org/jira/browse/IGNITE-14274 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We have to use converter rules to create single & map+reduce aggregates > instead of creates map/reduce aggregates on handle traits at the single > aggregates. > Now: > SortAggregateConverterRule > HashAggregateConverterRule > Must be: > SortSingleAggregateConverterRule > SortMapReduceAggregateConverterRule > HashSingleAggregateConverterRule > HashMapReduceAggregateConverterRule -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302684#comment-17302684
]
Konstantin Orlov commented on IGNITE-14214:
---
Hi, [~YAMolochkov]. The patch looks good in general, but I left a few comments
about minor issues. Please see PR.
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14326) Add CacheEntry#setTtl method
Stephen Darlington created IGNITE-14326:
---
Summary: Add CacheEntry#setTtl method
Key: IGNITE-14326
URL: https://issues.apache.org/jira/browse/IGNITE-14326
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 2.3
Reporter: Stephen Darlington
Assignee: Stephen Darlington
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key.
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14326) Add CacheEntry#setTtl method
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-14326:
Description:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
was:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key.
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html
> Add CacheEntry#setTtl method
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key or refresh the
> TTL without first retrieving the record.
> Ticket
> We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
> will provide this information. Looks like it's already available via
> {{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
> API.
> Here is the user forum discussion about this:
> [http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14326) Add CacheEntry#setTtl method
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-14326:
Description:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
_setting_ the TTL.
We can add {{CacheEntry#setTtl()}} and/or {{IgniteCache#setTtl(K key)}} method
that will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
was:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
> Add CacheEntry#setTtl method
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key or refresh the
> TTL without first retrieving the record.
> Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
> _setting_ the TTL.
> We can add {{CacheEntry#setTtl()}} and/or {{IgniteCache#setTtl(K key)}}
> method that will provide this information. Looks like it's already available
> via {{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to
> public API.
> Here is the user forum discussion about this:
> [http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14326) Add CacheEntry#setTtl method
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-14326:
Description:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
_setting_ the TTL.
The API for this is less well defined than the get TTL method. Suggest a number
of options:
* Update using the default TTL policy
* Update using a specified long
* Update using a specified Expiry policy
was:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
_setting_ the TTL.
We can add {{CacheEntry#setTtl()}} and/or {{IgniteCache#setTtl(K key)}} method
that will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
> Add CacheEntry#setTtl method
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key or refresh the
> TTL without first retrieving the record.
> Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
> _setting_ the TTL.
> The API for this is less well defined than the get TTL method. Suggest a
> number of options:
> * Update using the default TTL policy
> * Update using a specified long
> * Update using a specified Expiry policy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13748) Schema configuration public API
[ https://issues.apache.org/jira/browse/IGNITE-13748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13748: -- Description: Let's implement a public API classes for initial schema declaration. Considering next: * It should be possible to create schema without having any Class instance, like we do now with QueryEntity. * -Automatic schema creation based on annotated classes, like we have in ccfg.setIndexedTypes()- IGNITE-13749 * -Transient fields semantic.- IGNITE-13749 * Using builder pattern for schema configuration. * Split type-system into internal native-types (introduced IGNITE-13617) and public API types. The latest ones should be portable (e.g. could be used in .Net) * API can be extracted to separate module that will not have any dependency on other Ignite modules. was: Let's implement a public API classes for initial schema declaration. Considering next: * It should be possible to create schema without having any Class instance, like we do now with QueryEntity. * -Automatic schema creation based on annotated classes, like we have in ccfg.setIndexedTypes()- IGNITE-13749 * -Transient fields semantic.- IGNITE-13749 * Using builder pattern for schema configuration. * Split type-system into internal native-types (introduced GG-13617) and public API types. The latest ones should be portable (e.g. could be used in .Net) * API can be extracted to separate module that will not have any dependency on other Ignite modules. > Schema configuration public API > --- > > Key: IGNITE-13748 > URL: https://issues.apache.org/jira/browse/IGNITE-13748 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Let's implement a public API classes for initial schema declaration. > Considering next: > * It should be possible to create schema without having any Class instance, > like we do now with QueryEntity. > * -Automatic schema creation based on annotated classes, like we have in > ccfg.setIndexedTypes()- IGNITE-13749 > * -Transient fields semantic.- IGNITE-13749 > * Using builder pattern for schema configuration. > * Split type-system into internal native-types (introduced IGNITE-13617) and > public API types. The latest ones should be portable (e.g. could be used in > .Net) > * API can be extracted to separate module that will not have any dependency > on other Ignite modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14290) Implement Schema configuration API.
[ https://issues.apache.org/jira/browse/IGNITE-14290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14290: -- Summary: Implement Schema configuration API. (was: Implement Schema builders.) > Implement Schema configuration API. > --- > > Key: IGNITE-14290 > URL: https://issues.apache.org/jira/browse/IGNITE-14290 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Alexander Belyak >Priority: Major > Labels: iep-54, ignite-3 > > Implement schema configuration API from IGNITE-13748 and internal > SchemaDescriptor. > Initial Schema and Native types implementations are suggested in IGNITE-13617. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14077) Implement distributed SchemaManager.
[ https://issues.apache.org/jira/browse/IGNITE-14077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14077: -- Summary: Implement distributed SchemaManager. (was: Implement SchemaManager.) > Implement distributed SchemaManager. > > > Key: IGNITE-14077 > URL: https://issues.apache.org/jira/browse/IGNITE-14077 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > Create SchemaManager API and implement schema versioning logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14077) Implement distributed SchemaManager.
[ https://issues.apache.org/jira/browse/IGNITE-14077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14077: -- Description: Create SchemaManager API and implement schema versioning logic backed by distributed metastorage. was: Create SchemaManager API and implement schema versioning logic. > Implement distributed SchemaManager. > > > Key: IGNITE-14077 > URL: https://issues.apache.org/jira/browse/IGNITE-14077 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > Create SchemaManager API and implement schema versioning logic backed by > distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14316) Custom binary object API
[ https://issues.apache.org/jira/browse/IGNITE-14316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14316: -- Summary: Custom binary object API (was: BinaryObject API) > Custom binary object API > > > Key: IGNITE-14316 > URL: https://issues.apache.org/jira/browse/IGNITE-14316 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > Let's create BinaryObject (BO) interface and a builder interface for it > assuming > - BO is a self-described object. Similar to Ignite-2 one with a compact > footer. > - BO is unmanaged. SchemaManager doesn't care about its schema at all. > - BO can be deserialized to user class with a specified deserializer. > - BO has a flat structure, cyclic links are not allowed. However, one can > restore links on reserialization. > - BO must not have any dependencies on Ignite internals. > - Ignite should provide some base implementation for BO and builder. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14305) Snapshot check command for indexed cache ends with exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302892#comment-17302892
]
Maxim Muzafarov commented on IGNITE-14305:
--
Merged to the master branch, thank you for the review Pavel.
> Snapshot check command for indexed cache ends with exceptions
> -
>
> Key: IGNITE-14305
> URL: https://issues.apache.org/jira/browse/IGNITE-14305
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.11
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The snapshot validation command reports exceptions when executed on a
> snapshot containing cache with SQL-indexes.
> Reproducer
> {code:java}
> import org.apache.ignite.cache.QueryEntity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.processors.cache.verify.IdleVerifyResultV2;
> import org.apache.ignite.internal.util.typedef.F;
> import org.junit.Test;
> import static java.util.Collections.singletonList;
> public class IgniteClusterSnapshotCheckWithIndexesTest extends
> AbstractSnapshotSelfTest {
> private final CacheConfiguration indexedCcfg =
> txCacheConfig(new CacheConfiguration("indexed"))
> .setQueryEntities(singletonList(new
> QueryEntity(Integer.class.getName(), Account.class.getName(;
> @Test
> public void testClusterSnapshotCheckWithIndexes() throws Exception {
> IgniteEx ignite = startGridsWithCache(3, CACHE_KEYS_RANGE, key -> new
> Account(key, key), indexedCcfg);
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get();
> IdleVerifyResultV2 res =
> ignite.context().cache().context().snapshotMgr().checkSnapshot(SNAPSHOT_NAME).get();
> if (!F.isEmpty(res.exceptions())) {
> StringBuilder sb = new StringBuilder();
> res.print(sb::append, true);
> fail(sb.toString());
> }
> }
> }
> {code}
>
> Stderr output
> {noformat}
> java.lang.AssertionError: The check procedure failed on 3 nodes.
> The check procedure has finished, no conflicts have been found.
> The check procedure failed on nodes:
> Node ID: 1db72a3a-a1d8-48d7-9d25-96769312 [127.0.0.1]
> Consistent ID: snapshot.IgniteClusterSnapshotCheckWithIndexesTest2
> Exception: org.apache.ignite.IgniteException
> Snapshot data doesn't contain required cache group partition
> [grpId=1943292145, snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest2, missed=[65535],
> meta=SnapshotMetadata [rqId=7d5af20a-3247-41b4-a2d6-ed50bb63b249,
> snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest2,
> folderName=snapshot_IgniteClusterSnapshotCheckWithIndexesTest2,
> pageSize=4096, grpIds=ArrayList [1943292145], bltNodes=HashSet
> [snapshot.IgniteClusterSnapshotCheckWithIndexesTest2,
> snapshot.IgniteClusterSnapshotCheckWithIndexesTest1,
> snapshot.IgniteClusterSnapshotCheckWithIndexesTest0], locParts=HashMap
> {1943292145=HashSet [0, 1, 2, 3, 4, 5, 6, 7, 65535]}]]
> Node ID: e49c924f-3fae-40ca-bb7c-c6905281 [127.0.0.1]
> Consistent ID: snapshot.IgniteClusterSnapshotCheckWithIndexesTest1
> Exception: org.apache.ignite.IgniteException
> Snapshot data doesn't contain required cache group partition
> [grpId=1943292145, snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest1, missed=[65535],
> meta=SnapshotMetadata [rqId=7d5af20a-3247-41b4-a2d6-ed50bb63b249,
> snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest1,
> folderName=snapshot_IgniteClusterSnapshotCheckWithIndexesTest1,
> pageSize=4096, grpIds=ArrayList [1943292145], bltNodes=HashSet
> [snapshot.IgniteClusterSnapshotCheckWithIndexesTest2,
> snapshot.IgniteClusterSnapshotCheckWithIndexesTest1,
> snapshot.IgniteClusterSnapshotCheckWithIndexesTest0], locParts=HashMap
> {1943292145=HashSet [0, 1, 2, 3, 4, 5, 6, 7, 65535]}]]
> Node ID: dba1b3fa-e37a-4b79-878d-018bfc40 [127.0.0.1]
> Consistent ID: snapshot.IgniteClusterSnapshotCheckWithIndexesTest0
> Exception: org.apache.ignite.IgniteException
> Snapshot data doesn't contain required cache group partition
> [grpId=1943292145, snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest0, missed=[65535],
> meta=SnapshotMetadata [rqId=7d5af20a-3247-41b4-a2d6-ed50bb63b249,
> snpName=testSnapshot,
> consId=snapshot.IgniteClusterSnapshotCheckWithIndexesTest0,
> folderName=snapshot_IgniteClusterSnapshotCheckWithIndexesTest0,
> pageSize=4096, grpIds=ArrayList [1943292145], bltNodes=HashSet
> [snapshot.IgniteClusterSnapshotCheckWithIndexesTest2,
> sn
[jira] [Commented] (IGNITE-14247) Add documentation pages for snapshot check command
[ https://issues.apache.org/jira/browse/IGNITE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302894#comment-17302894 ] Maxim Muzafarov commented on IGNITE-14247: -- Nikita, thank you for the review. Merged to the master branch. > Add documentation pages for snapshot check command > -- > > Key: IGNITE-14247 > URL: https://issues.apache.org/jira/browse/IGNITE-14247 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.11 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The snapshot check command must be properly documented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li updated IGNITE-12852: -- Fix Version/s: 2.11 > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.11 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14327) Flaky IgniteCacheNearRestartRollbackSelfTest.
Stanilovsky Evgeny created IGNITE-14327: --- Summary: Flaky IgniteCacheNearRestartRollbackSelfTest. Key: IGNITE-14327 URL: https://issues.apache.org/jira/browse/IGNITE-14327 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.10 Reporter: Stanilovsky Evgeny Attachments: image-2021-03-17-08-39-28-729.png, image-2021-03-17-08-40-29-865.png IgniteCacheNearRestartRollbackSelfTest seems flaky, !image-2021-03-17-08-39-28-729.png! !image-2021-03-17-08-40-29-865.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita reassigned IGNITE-14214:
Assignee: Amelchev Nikita (was: Yaroslav Molochkov)
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14308) IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare deployable, because local node id does not correspond with class loader id
[
https://issues.apache.org/jira/browse/IGNITE-14308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303132#comment-17303132
]
Sergey Chugunov commented on IGNITE-14308:
--
[~ilyak],
Change looks good to me, please proceed with merge. Thanks!
> IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare
> deployable, because local node id does not correspond with class loader id
> -
>
> Key: IGNITE-14308
> URL: https://issues.apache.org/jira/browse/IGNITE-14308
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-12760, the following exception is seen:
> {code}
> IgnitePeerToPeerClassLoadingException
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.checkDeploymentIsCorrect(GridCacheDeploymentManager.java:717)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.prepare(GridCacheDeploymentManager.java:693)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1245)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:570)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:381)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:324)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:128)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3965)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:4013)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2958)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAllAsync0(GridNearTxLocal.java:1033)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:540)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2389)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:3830)
> ... 29 more
> {code}
> Turns out, sometimes local deployment belongs to other node id (previous
> client?). Changing behavior for local deployments was not anticipated. Let's
> change this error to warning for local deployments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14308) IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare deployable, because local node id does not correspond with class loader id
[
https://issues.apache.org/jira/browse/IGNITE-14308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-14308:
-
Reviewer: Sergey Chugunov
> IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare
> deployable, because local node id does not correspond with class loader id
> -
>
> Key: IGNITE-14308
> URL: https://issues.apache.org/jira/browse/IGNITE-14308
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-12760, the following exception is seen:
> {code}
> IgnitePeerToPeerClassLoadingException
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.checkDeploymentIsCorrect(GridCacheDeploymentManager.java:717)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.prepare(GridCacheDeploymentManager.java:693)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1245)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:570)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:381)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:324)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:128)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3965)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:4013)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2958)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAllAsync0(GridNearTxLocal.java:1033)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:540)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2389)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:3830)
> ... 29 more
> {code}
> Turns out, sometimes local deployment belongs to other node id (previous
> client?). Changing behavior for local deployments was not anticipated. Let's
> change this error to warning for local deployments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
