[jira] [Commented] (IGNITE-13172) Module ignite-scalar compilation error on JDK 11+
[
https://issues.apache.org/jira/browse/IGNITE-13172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143492#comment-17143492
]
Ignite TC Bot commented on IGNITE-13172:
{panel:title=Branch: [pull/7955/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7955/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=3abed227-cdcd-49ba-9a09-10d566586fd6, topVer=0,
nodeId8=0e74c947, msg=, type=NODE_JOINED, tstamp=1592898572620],
val2=AffinityTopologyVersion [topVer=3243828459318014916, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=0515720e271-48ccb89d-60ba-48d7-a759-808ceea95696, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=4587ae75-6de9-46bd-ba6f-dd357f4c1b52, topVer=0, nodeId8=4587ae75,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592898572620]],
val2=AffinityTopologyVersion [topVer=-8485662505985071933, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=0515720e271-48ccb89d-60ba-48d7-a759-808ceea95696, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=4587ae75-6de9-46bd-ba6f-dd357f4c1b52, topVer=0, nodeId8=4587ae75,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592898572620]],
val2=AffinityTopologyVersion [topVer=-8485662505985071933, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=3abed227-cdcd-49ba-9a09-10d566586fd6, topVer=0,
nodeId8=0e74c947, msg=, type=NODE_JOINED, tstamp=1592898572620],
val2=AffinityTopologyVersion [topVer=3243828459318014916, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=2253cf8c-e8e5-4e98-a631-b7e618f84b9b, topVer=0,
nodeId8=a1855a2e, msg=, type=NODE_JOINED, tstamp=1592898760129],
val2=AffinityTopologyVersion [topVer=-4603834801483763879, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=2253cf8c-e8e5-4e98-a631-b7e618f84b9b, topVer=0,
nodeId8=a1855a2e, msg=, type=NODE_JOINED, tstamp=1592898760129],
val2=AffinityTopologyVersion [topVer=-4603834801483763879, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3827430e271-0e1fcc2e-428a-45c4-aacc-67eaab3f1afb, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d0f2613f-3355-45a5-9dfc-ee5d9b4b5a07, topVer=0, nodeId8=d0f2613f,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592898760129]],
val2=AffinityTopologyVersion [topVer=3961144377987927277, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3827430e271-0e1fcc2e-428a-45c4-aacc-67eaab3f1afb, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d0f2613f-3355-45a5-9dfc-ee5d9b4b5a07, topVer=0, nodeId8=d0f2613f,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592898760129]],
val2=AffinityTopologyVersion [topVer=3961144377987927277, minorTopVer=0]]] -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5411264&buildTypeId=IgniteTests24Java8_RunAll]
> Module ignite-scalar compilation error on JDK 11+
> -
>
> Key: IGNITE-13172
> URL: https://issues.apache.org/jira/browse/IGNITE-13172
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Module ignite-scalar can't be compiled by maven on JDK 11+.
> There is an error on scala-maven-pl
[jira] [Updated] (IGNITE-13178) Spark job gets stuck indefinitely while trying to fetch data from ignite cluster using thin client
[
https://issues.apache.org/jira/browse/IGNITE-13178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ameer Basha Pattan updated IGNITE-13178:
Description:
We are trying to use ignite as in-memory distributed cache and put data inside
cache using spark job.
We tried using thin client to fetch data from cache.
// we are using ThreadLocal to stop creating too many client instances.
private static final ThreadLocal igniteClientContext = new
ThreadLocal<>();
//Thin client creation
public static IgniteClient getIgniteClient(String[] address) {
if(igniteClientContext.get() == null) { ClientConfiguration clientConfig =
null; if(cfg == null)
{ clientConfig = new ClientConfiguration().setAddresses(address); }
else \{ clientConfig = cfg; } IgniteClient igniteClient =
Ignition.startClient(clientConfig); logger.info("igniteClient initialized ");
igniteClientContext.set(igniteClient); } return igniteClientContext.get(); }
>From spark code, I'm trying to create instance of ignite thin client and
>create cache object.
{{val address = config.igniteServers.split(",") // config.igniteServers
="10.xx.xxx.xxx:10800,10.xx.xx.xxx:10800"}}
{{}}
Below code will be called from spark executor. We will be processing set or
records in each executor and we are only reading data from cache and comparing
with currently processing record. If it is already present in cache, we will
ignore otherwise we will consume it.
{{}}
{{val cacheCfg = new ClientCacheConfiguration()
.setName(PNR_CACHE)
.setCacheMode(CacheMode.REPLICATED)
.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC)
.setDefaultLockTimeout(3)
val igniteClient = IgniteHelper.getIgniteClient(address)
val cache : ClientCache[Long, Boolean] =
igniteClient.getOrCreateCache(cacheCfg);}}
{{}}
{{Job is running fine for couple of hours and it gets stuck with below
exception indefinitely.}}
{{}}
{{org.apache.ignite.client.ClientConnectionException: Ignite cluster is
unavailable
[sock=Socket[addr=hdpct2ldap01g02.hadoop.sgdcprod..com/10.xx.xx.xx,port=10800,localport=20214]]
at
org.apache.ignite.internal.client.thin.TcpClientChannel.handleIOError(TcpClientChannel.java:499)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.handleIOError(TcpClientChannel.java:491)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.access$100(TcpClientChannel.java:92)
at
org.apache.ignite.internal.client.thin.TcpClientChannel$ByteCountingDataInput.read(TcpClientChannel.java:538)
at
org.apache.ignite.internal.client.thin.TcpClientChannel$ByteCountingDataInput.readInt(TcpClientChannel.java:572)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.processNextResponse(TcpClientChannel.java:272)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:234)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:171)
at
org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:160)
at
org.apache.ignite.internal.client.thin.ReliableChannel.request(ReliableChannel.java:187)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.getOrCreateCache(TcpIgniteClient.java:124)
at
com..eda.pnr.PnrApplication$$anonfun$2$$anonfun$apply$4.apply(PnrApplication.scala:305)
at
com..eda.pnr.PnrApplication$$anonfun$2$$anonfun$apply$4.apply(PnrApplication.scala:297)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at
org.apache.spark.storage.memory.MemoryStore.putIteratorAsValues(MemoryStore.scala:217)
at
org.apache.spark.storage.BlockManager$$anonfun$doPutIterator$1.apply(BlockManager.scala:1094)
at
org.apache.spark.storage.BlockManager$$anonfun$doPutIterator$1.apply(BlockManager.scala:1085)
at org.apache.spark.storage.BlockManager.doPut(BlockManager.scala:1020)
at org.apache.spark.storage.BlockManager.doPutIterator(BlockManager.scala:1085)
at
org.apache.spark.storage.BlockManager.getOrElseUpdate(BlockManager.scala:811)
at org.apache.spark.rdd.RDD.getOrCompute(RDD.scala:335)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:286)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
at org.apache.spark.scheduler.Task.run(Task.scala:109)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:381)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.SocketException: Connection timed out (Read failed)
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at
org.apache.ignite.internal.client.thin.TcpClientChann
[jira] [Commented] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143347#comment-17143347 ] Denis A. Magda commented on IGNITE-13169: - [~sdanilov], The changes look reasonable to me. Thanks for improving the integration! I left a couple of review notes in the pull-request. Btw, will this improvement solve the other issue I reported earlier? https://issues.apache.org/jira/browse/IGNITE-13029 It sounds like you hit the issue described in that ticket. > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143337#comment-17143337
]
Ignite TC Bot commented on IGNITE-13012:
{panel:title=Branch: [pull/7835/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7835/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=1ecde8ca-c835-40f0-84b5-5f120652fb34, topVer=0,
nodeId8=79b4c8bd, msg=, type=NODE_JOINED, tstamp=1592922924152],
val2=AffinityTopologyVersion [topVer=-8557124388581407890, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=1ecde8ca-c835-40f0-84b5-5f120652fb34, topVer=0,
nodeId8=79b4c8bd, msg=, type=NODE_JOINED, tstamp=1592922924152],
val2=AffinityTopologyVersion [topVer=-8557124388581407890, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c74ea91e271-8b81e6bf-0900-4345-acaf-b97f401e49ba, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=60097310-0e55-46a9-a3f4-d4ba4e0302fc, topVer=0, nodeId8=60097310,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592922924152]],
val2=AffinityTopologyVersion [topVer=-5196826382153774944, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c74ea91e271-8b81e6bf-0900-4345-acaf-b97f401e49ba, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=60097310-0e55-46a9-a3f4-d4ba4e0302fc, topVer=0, nodeId8=60097310,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592922924152]],
val2=AffinityTopologyVersion [topVer=-5196826382153774944, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b4b39a84-6c25-448d-89ea-3eccee841eac, topVer=0,
nodeId8=e5615957, msg=, type=NODE_JOINED, tstamp=1592923013555],
val2=AffinityTopologyVersion [topVer=-3939455393161335600, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b4b39a84-6c25-448d-89ea-3eccee841eac, topVer=0,
nodeId8=e5615957, msg=, type=NODE_JOINED, tstamp=1592923013555],
val2=AffinityTopologyVersion [topVer=-3939455393161335600, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=f91e5a1e271-baed6732-c5c9-4be1-9fab-4390a574bd30, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=b7fe7817-4e52-460f-b0ff-f2537b5f2845, topVer=0, nodeId8=b7fe7817,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592923013555]],
val2=AffinityTopologyVersion [topVer=-5941968585139194205, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=f91e5a1e271-baed6732-c5c9-4be1-9fab-4390a574bd30, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=b7fe7817-4e52-460f-b0ff-f2537b5f2845, topVer=0, nodeId8=b7fe7817,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592923013555]],
val2=AffinityTopologyVersion [topVer=-5941968585139194205, minorTopVer=0]]] -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5412147&buildTypeId=IgniteTests24Java8_RunAll]
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 3.
[jira] [Updated] (IGNITE-13127) Master key change can produce exception in discovery notifier worker when WAL is disabled.
[
https://issues.apache.org/jira/browse/IGNITE-13127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-13127:
--
Summary: Master key change can produce exception in discovery notifier
worker when WAL is disabled. (was: Master key change can produce exception in
discovery notyfier worker when WAL is disabled.)
> Master key change can produce exception in discovery notifier worker when WAL
> is disabled.
> --
>
> Key: IGNITE-13127
> URL: https://issues.apache.org/jira/browse/IGNITE-13127
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Minor
>
> When WALMode is set to NONE, master key change may produce the following
> error.
> {noformat}
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
> java.lang.AssertionError
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToWal(GridEncryptionManager.java:1679)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:1642)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1821)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:150)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer
> {code:java}
> @Override protected IgniteConfiguration getConfiguration(String name)
> throws Exception {
> KeystoreEncryptionSpi encSpi = new KeystoreEncryptionSpi();
>
> encSpi.setKeyStorePath(resolveIgnitePath("modules/core/src/test/resources/tde.jks").getAbsolutePath());
> encSpi.setKeyStorePassword("love_sex_god".toCharArray());
> DataStorageConfiguration memCfg = new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setMaxSize(10L * 1024 * 1024)
> .setPersistenceEnabled(true))
> .setWalMode(NONE);
> return super.getConfiguration(name).
> setDataStorageConfiguration(memCfg).
> setEncryptionSpi(encSpi);
> }
> @Test
> public void testChangeMasterKey() throws Exception {
> Ignite node0 = startGrid(0);
> node0.cluster().state(ClusterState.ACTIVE);
> node0.encryption().changeMasterKey(MASTER_KEY_NAME_2).get();
> }
> {code}
> For in-memory cluster master key rotation produces the following error:
> {noformat}
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteException: Unable to change
> master key locally.]]
> class org.apache.ignite.IgniteException: Unable to change master key locally.
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:1658)
> at
> org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1821)
> at
> org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:150)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
> at
> org.apache
[jira] [Commented] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143224#comment-17143224 ] Semyon Danilov commented on IGNITE-13169: - [~mnusan] It's really impressive work! But I'm not sure if such massive code change will go to the nearest release and I really wanted to fix this small issue :) > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11189) Support Java 11 for Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-11189. -- Resolution: Done > Support Java 11 for Apache Ignite > - > > Key: IGNITE-11189 > URL: https://issues.apache.org/jira/browse/IGNITE-11189 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Priority: Major > Labels: important, jdk11 > Time Spent: 10m > Remaining Estimate: 0h > > This is an umbrella ticket to link all Java 11 related efforts in one ticket. > 'Blocked by' link type is used in case change is mandatory to be done. > Other link types, e.g. 'related to' used for nice-to-have fixes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11189) Support Java 11 for Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11189: - Ignite Flags: (was: Docs Required,Release Notes Required) > Support Java 11 for Apache Ignite > - > > Key: IGNITE-11189 > URL: https://issues.apache.org/jira/browse/IGNITE-11189 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Priority: Major > Labels: important, jdk11 > Time Spent: 10m > Remaining Estimate: 0h > > This is an umbrella ticket to link all Java 11 related efforts in one ticket. > 'Blocked by' link type is used in case change is mandatory to be done. > Other link types, e.g. 'related to' used for nice-to-have fixes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13155) Snapshot creation throws NPE on an in-memory cluster
[
https://issues.apache.org/jira/browse/IGNITE-13155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143098#comment-17143098
]
Ignite TC Bot commented on IGNITE-13155:
{panel:title=Branch: [pull/7959/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7959/head] Base: [master] : New Tests
(9)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 3{color} [tests 1]
* {color:#013220}IgniteBasicWithPersistenceTestSuite:
IgniteClusterSnapshotSelfTest.testClusterSnapshotInMemoryFail - PASSED{color}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f65a010e-7eb0-421e-a190-a5778227b480, topVer=0,
nodeId8=b5e8b81b, msg=, type=NODE_JOINED, tstamp=1592916679570],
val2=AffinityTopologyVersion [topVer=3166092571334886376, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f65a010e-7eb0-421e-a190-a5778227b480, topVer=0,
nodeId8=b5e8b81b, msg=, type=NODE_JOINED, tstamp=1592916679570],
val2=AffinityTopologyVersion [topVer=3166092571334886376, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=69b9b31e271-327e07b8-9a3d-42ce-bbfd-3b76e6a7abc0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=f5671c42-67df-4376-8417-eb5df2cbd9f3, topVer=0, nodeId8=f5671c42,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592916679570]],
val2=AffinityTopologyVersion [topVer=8216335546365876411, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=69b9b31e271-327e07b8-9a3d-42ce-bbfd-3b76e6a7abc0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=f5671c42-67df-4376-8417-eb5df2cbd9f3, topVer=0, nodeId8=f5671c42,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592916679570]],
val2=AffinityTopologyVersion [topVer=8216335546365876411, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=d61ff1da-db08-45a5-b2df-45e4dd5bac25, topVer=0,
nodeId8=5ec79633, msg=, type=NODE_JOINED, tstamp=1592916710660],
val2=AffinityTopologyVersion [topVer=-7750721404924766070, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=d61ff1da-db08-45a5-b2df-45e4dd5bac25, topVer=0,
nodeId8=5ec79633, msg=, type=NODE_JOINED, tstamp=1592916710660],
val2=AffinityTopologyVersion [topVer=-7750721404924766070, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=61a3641e271-6d6da8b0-b287-4857-8456-76d238616eec, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=34f1b15e-628d-4231-a758-9c9ff2104b2b, topVer=0, nodeId8=34f1b15e,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592916710660]],
val2=AffinityTopologyVersion [topVer=3268757439735711942, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=61a3641e271-6d6da8b0-b287-4857-8456-76d238616eec, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=34f1b15e-628d-4231-a758-9c9ff2104b2b, topVer=0, nodeId8=34f1b15e,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592916710660]],
val2=AffinityTopologyVersion [topVer=3268757439735711942, minorTopVer=0]]] -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5411892&buildTypeId=IgniteTests24Java8_RunAll]
> Snapshot creation throws NPE on an in-memory cluster
>
>
> Key: IGNITE-13155
> URL: https://issues.apache.org/jira/browse/IGNITE-13155
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Prio
[jira] [Commented] (IGNITE-13066) Test framework must print which tests for quite mode
[
https://issues.apache.org/jira/browse/IGNITE-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143090#comment-17143090
]
Maxim Muzafarov commented on IGNITE-13066:
--
Merged to the master branch.
> Test framework must print which tests for quite mode
>
>
> Key: IGNITE-13066
> URL: https://issues.apache.org/jira/browse/IGNITE-13066
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For most of the TeamCity test suites logger is turned off for performance
> reasons (log size can be more than a thousand MB). In case of exceptions
> happened it's hard to identify which of running tests fail.
> It is necessary to log which tests are started regardless of the logger
> configured or not.
> Example:
> {code:java}
> info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13066) Test framework must print which tests for quite mode
[
https://issues.apache.org/jira/browse/IGNITE-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13066:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Test framework must print which tests for quite mode
>
>
> Key: IGNITE-13066
> URL: https://issues.apache.org/jira/browse/IGNITE-13066
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For most of the TeamCity test suites logger is turned off for performance
> reasons (log size can be more than a thousand MB). In case of exceptions
> happened it's hard to identify which of running tests fail.
> It is necessary to log which tests are started regardless of the logger
> configured or not.
> Example:
> {code:java}
> info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13180) AuthenticationContext does not contain subject address when subject is IgniteClient
[ https://issues.apache.org/jira/browse/IGNITE-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-13180: --- Description: AuthenticationContext does not contain subject address when subject is IgniteClient (was: Thin client address missing in authentication context) > AuthenticationContext does not contain subject address when subject is > IgniteClient > --- > > Key: IGNITE-13180 > URL: https://issues.apache.org/jira/browse/IGNITE-13180 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > > AuthenticationContext does not contain subject address when subject is > IgniteClient -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13066) Test framework must print which tests for quite mode
[
https://issues.apache.org/jira/browse/IGNITE-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13066:
-
Fix Version/s: 2.9
> Test framework must print which tests for quite mode
>
>
> Key: IGNITE-13066
> URL: https://issues.apache.org/jira/browse/IGNITE-13066
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For most of the TeamCity test suites logger is turned off for performance
> reasons (log size can be more than a thousand MB). In case of exceptions
> happened it's hard to identify which of running tests fail.
> It is necessary to log which tests are started regardless of the logger
> configured or not.
> Example:
> {code:java}
> info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13180) AuthenticationContext does not contain subject address when subject is IgniteClient
[ https://issues.apache.org/jira/browse/IGNITE-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-13180: --- Summary: AuthenticationContext does not contain subject address when subject is IgniteClient (was: Thin client address missing in authentication context) > AuthenticationContext does not contain subject address when subject is > IgniteClient > --- > > Key: IGNITE-13180 > URL: https://issues.apache.org/jira/browse/IGNITE-13180 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > > Thin client address missing in authentication context -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13066) Test framework must print which tests for quite mode
[
https://issues.apache.org/jira/browse/IGNITE-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143088#comment-17143088
]
Maxim Muzafarov commented on IGNITE-13066:
--
Discussed with Ilya privately - merge this issue first and then integrate TC
under IGNITE-12934
> Test framework must print which tests for quite mode
>
>
> Key: IGNITE-13066
> URL: https://issues.apache.org/jira/browse/IGNITE-13066
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For most of the TeamCity test suites logger is turned off for performance
> reasons (log size can be more than a thousand MB). In case of exceptions
> happened it's hard to identify which of running tests fail.
> It is necessary to log which tests are started regardless of the logger
> configured or not.
> Example:
> {code:java}
> info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13180) Thin client address missing in authentication context
[ https://issues.apache.org/jira/browse/IGNITE-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-13180: --- Description: Thin client address missing in authentication context (was: AuthenticationContext should contain the address when connecting the IgniteClient and using IgniteSecurity) > Thin client address missing in authentication context > - > > Key: IGNITE-13180 > URL: https://issues.apache.org/jira/browse/IGNITE-13180 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > > Thin client address missing in authentication context -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13180) Thin client address missing in authentication context
[ https://issues.apache.org/jira/browse/IGNITE-13180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-13180: --- Summary: Thin client address missing in authentication context (was: AuthenticationContext should contain the address when connecting the IgniteClient and using IgniteSecurity) > Thin client address missing in authentication context > - > > Key: IGNITE-13180 > URL: https://issues.apache.org/jira/browse/IGNITE-13180 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > > AuthenticationContext should contain the address when connecting the > IgniteClient and using IgniteSecurity -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13180) AuthenticationContext should contain the address when connecting the IgniteClient and using IgniteSecurity
Sergei Ryzhov created IGNITE-13180: -- Summary: AuthenticationContext should contain the address when connecting the IgniteClient and using IgniteSecurity Key: IGNITE-13180 URL: https://issues.apache.org/jira/browse/IGNITE-13180 Project: Ignite Issue Type: Task Components: thin client Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov AuthenticationContext should contain the address when connecting the IgniteClient and using IgniteSecurity -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13155) Snapshot creation throws NPE on an in-memory cluster
[
https://issues.apache.org/jira/browse/IGNITE-13155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143080#comment-17143080
]
Amelchev Nikita commented on IGNITE-13155:
--
[~mmuzaf], LGTM. I have left comments about minor issues.
> Snapshot creation throws NPE on an in-memory cluster
>
>
> Key: IGNITE-13155
> URL: https://issues.apache.org/jira/browse/IGNITE-13155
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Snapshot creation throws NPE on an in-memory cluster.
> {code}
> Error stack trace:
> class org.apache.ignite.internal.client.GridClientException: Failed to handle
> request: [req=EXE,
> taskName=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask,
> params=[VisorTaskArgument [debug=false]], err=Failed to reduce job results
> due to undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null], trace=class
> org.apache.ignite.IgniteCheckedException: Failed to reduce job results due to
> undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7566)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:263)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:325)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:104)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:179)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException:
> Failed to reduce job results due to undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1184)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:974)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processDelayedResponses(GridTaskWorker.java:711)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:542)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:830)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:555)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:535)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
> ... 8 more
> Caused by: class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1086)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(Ign
[jira] [Commented] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143072#comment-17143072
]
Ilya Kasnacheev commented on IGNITE-13005:
--
[~mnusan] please fix compilation errors. We can't run MTCGA if there are
compilation errors:
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite/5411396
While you're there, please reformat coding guidelines (such as, else block
starting on new line, no blank line on start of method/class, every
field/method has a javadoc comment even if empty, @Override on the same line as
method name) and fix Travis CI shown on pull request page.
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> Spring Data 2 - "JPA style" and working with multiple Ignite instances on
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Assignee: Manuel Núñez
>Priority: Major
> Labels: spring-data
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some
> interesting improvements.
> Code is 100% compatible with previous versions.
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
> * Supports multiple ignite instances on same JVM (@RepositoryConfig).
> * Supports query tuning parameters in {{@Query}} annotation
> * Supports projections
> * Supports {{Page}} and {{Stream}} responses
> * Supports Sql Fields Query resultset transformation into the domain entity
> * Supports named parameters ({{:myParam}}) into SQL queries, declared using
> {{@Param("myParam")}}
> * Supports advanced parameter binding and SpEL expressions into SQL queries:
> ** *Template variables*:
> *** {{#entityName}} - the simple class name of the domain entity
> ** *Method parameter expressions*: Parameters are exposed for indexed access
> ({{[0]}} is the first query method's param) or via the name declared using
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}.
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
> ** *Advanced SpEL expressions*: While advanced parameter binding is a very
> useful feature, the real power of SpEL stems from the fact, that the
> expressions can refer to framework abstractions or other application
> components through SpEL EvaluationContext extension model.
> * Supports SpEL expressions into Text queries ({{TextQuery}}).
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city")
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity =
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "email: #{#email}")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "#{#textToSearch}")
> List searchUsersByText(@Param("textToSearch") String text, Pageable
> pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL indexed parameter
> @Query(textQuery = true, value = "#{[0]}")
> List searchUsersByText(String textToSearch, Pageable pageable);
> {code}
> {code:java}
> // Static Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.i
[jira] [Created] (IGNITE-13179) Calcite integration. Fix traits at the IgniteLimit
Taras Ledkov created IGNITE-13179:
-
Summary: Calcite integration. Fix traits at the IgniteLimit
Key: IGNITE-13179
URL: https://issues.apache.org/jira/browse/IGNITE-13179
Project: Ignite
Issue Type: Improvement
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Current implementation of {{IgniteLimit}} doesn't support distribution trait
propagation.
Limit must require singleton distribution.
Now we cannot reproduce invalid behavior (see IGNITE-12819) and IgniteLimit
isn't placed under the Exchange node.
Also Limit must be propogated (copied) under Exchange to reduce unnecessary
fetches.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13155) Snapshot creation throws NPE on an in-memory cluster
[
https://issues.apache.org/jira/browse/IGNITE-13155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13155:
-
Labels: iep-43 (was: )
> Snapshot creation throws NPE on an in-memory cluster
>
>
> Key: IGNITE-13155
> URL: https://issues.apache.org/jira/browse/IGNITE-13155
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Snapshot creation throws NPE on an in-memory cluster.
> {code}
> Error stack trace:
> class org.apache.ignite.internal.client.GridClientException: Failed to handle
> request: [req=EXE,
> taskName=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask,
> params=[VisorTaskArgument [debug=false]], err=Failed to reduce job results
> due to undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null], trace=class
> org.apache.ignite.IgniteCheckedException: Failed to reduce job results due to
> undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7566)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:263)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:325)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:104)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:179)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException:
> Failed to reduce job results due to undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1184)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:974)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processDelayedResponses(GridTaskWorker.java:711)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:542)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:830)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:555)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:535)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
> ... 8 more
> Caused by: class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1086)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:168)
> at
> org.apache.ignite.internal.util.future.IgniteFutur
[jira] [Commented] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142954#comment-17142954
]
Sergey Chugunov commented on IGNITE-13012:
--
[~vladsz83],
Now patch looks good to me as well. Please merge it to master branch.
Thanks!
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13154) Introduce the ability for a user to manage binary types
[
https://issues.apache.org/jira/browse/IGNITE-13154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142947#comment-17142947
]
Ignite TC Bot commented on IGNITE-13154:
{panel:title=Branch: [pull/7936/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Binary Objects{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5410148]]
* IgniteBinaryObjectsTestSuite:
BinaryMetadataRemoveWithPersistenceTest.testRemoveTypeAndClusterRestart - New
test duration 68s is more that 1 minute
{panel}
{panel:title=Branch: [pull/7936/head] Base: [master] : New Tests
(21)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 7{color} [tests 6]
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testMetadataDetails - PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testMetadataList - PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testDropJdbcThinConnectionsOnRemove -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testInvalidArguments - PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testRemoveUpdate - PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testDropThinConnectionsOnRemove - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8d2ec1b5-c0b4-4c38-a6b0-f1118b3f62a2, topVer=0,
nodeId8=3e4a66c9, msg=, type=NODE_JOINED, tstamp=1592830998672],
val2=AffinityTopologyVersion [topVer=-8281822966745144678, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8d2ec1b5-c0b4-4c38-a6b0-f1118b3f62a2, topVer=0,
nodeId8=3e4a66c9, msg=, type=NODE_JOINED, tstamp=1592830998672],
val2=AffinityTopologyVersion [topVer=-8281822966745144678, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=498302cd271-2933ee5e-fe25-4d03-9783-c1b576d29701, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=f64161f5-e63d-4694-8109-887dde4fb805, topVer=0, nodeId8=f64161f5,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592830998672]],
val2=AffinityTopologyVersion [topVer=4960202716760150737, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=498302cd271-2933ee5e-fe25-4d03-9783-c1b576d29701, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=f64161f5-e63d-4694-8109-887dde4fb805, topVer=0, nodeId8=f64161f5,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592830998672]],
val2=AffinityTopologyVersion [topVer=4960202716760150737, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=ae5ccaaa-9faa-4e76-ba6a-012bda1a486e, topVer=0,
nodeId8=960612cf, msg=, type=NODE_JOINED, tstamp=1592831016351],
val2=AffinityTopologyVersion [topVer=6230885601264143063, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3ad702cd271-3d0b6d17-6fa8-4d3f-9821-a01807fef461, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=c254a185-5ca3-4ee3-a213-b96443a3dcf7, topVer=0, nodeId8=c254a185,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592831016351]],
val2=AffinityTopologyVersion [topVer=-616247404138074378, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3ad702cd271-3d0b6d17-6fa8-4d3f-9821-a01807fef461, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=c254a185-5ca3-4ee3-a213-b96443a3dcf7, topVer=0, nodeId8=c254a185,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1592831016351]],
val2=AffinityT
[jira] [Commented] (IGNITE-13154) Introduce the ability for a user to manage binary types
[
https://issues.apache.org/jira/browse/IGNITE-13154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142952#comment-17142952
]
Taras Ledkov commented on IGNITE-13154:
---
[~korlov], [~amashenkov], all review comments are fixed. Please review the
patch.
> Introduce the ability for a user to manage binary types
> ---
>
> Key: IGNITE-13154
> URL: https://issues.apache.org/jira/browse/IGNITE-13154
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> We need a way to change schema (including unsupported changes, such as column
> type change) without cluster restart. This is for the case when all data
> associated with the binary type has been removed, so removing the old schema
> is safe.
> Now users must stop the cluster and remove the folder with binary metadata
> manually.
> The proposed way is to introduce internal API to manage binary types and
> public command line interface (via control.sh). That way one can remove a
> cache from the cluster, then unregister corresponding binary types, then
> launch a new version of an application that would register the new schema and
> reload the data.
> *The current implementation has restrictions:*
> - all cluster nodes must support remove type feature.
> - the cluster must not contains data with type to remove.
> - operation of the update type must not be launched on the cluster for the
> type to remove (operation examples: put into cache,
> BinaryObjectBuilder#build).
> - client nodes process metadata operation asynchronously so type may be
> removed at the client after any delay after the remove type operation is
> completed.
> - if the node that contains the old version of the type joins to the cluster
> where type was removed the type is propagated to cluster metadata (because
> metadata tombstone not supported).
> - if the node that contains the old version of the type cannot join to the
> cluster where type was removed and then updated to the new version (because
> metadata versioned tombstone not supported).
> So, user scenarios looks like:
> # Be sure that all server nodes supports remove type feature.
> # Remove caches contains the data with type to remove.
> # Stops the client node with older version.
> # Stops all operation with type to remove (don't create binary objects, don't
> run compute jobs with type to remove).
> # Remove the type on the stable topology (and production destination topolog).
> # Waits any delay (depends on the cluster size and clients count)
> # Produce operations with new version of the type.
> *Proposed command line interface*
> New commands (all commands are _experimental_ ):
> - {{--meta list}} prints info about all available binary types:
> {{typeId=, typeName=, fields=,
> schemas=, isEnum=}}
> - {{\-\-meta details (\-\- typeId | \-\-typeName )}} prints
> detailed info info about specified type. The type may be specified by type
> name or type ID.
> output example:
> {code}
> typeId=0x1FBFBC0C (532659212)
> typeName=TypeName1
> Fields:
> name=fld3, type=long[], fieldId=0x2FFF95 (3145621)
> name=fld2, type=double, fieldId=0x2FFF94 (3145620)
> name=fld1, type=Date, fieldId=0x2FFF93 (3145619)
> name=fld0, type=int, fieldId=0x2FFF92 (3145618)
> Schemas:
> schemaId=0x6C5CC179 (1818018169), fields=[fld0]
> schemaId=0x70E46431 (1894016049), fields=[fld0, fld1, fld2, fld3]
> {code}
> - {{\-\-meta remove (\-\- typeId | \-\-typeName ) [\-\-out
> ]}} removes metadata for specified type form cluster and saves the
> removed metadata to the specified file. If the file name isn't specified the
> output file name is: {{.bin}}
> The command requires confirmation.
> *N.B.*: The all session of thin clients (ODBC, JDBC, thin client) are closed
> (to cleanup local cache of the binary metadata).
> - {{\-\-meta update \-\-in ]}} update cluster metadata from
> specified file (file name is required)
> The command requires confirmation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142895#comment-17142895
]
Sergey Chugunov commented on IGNITE-13012:
--
[~avinogradov], [~vladsz83], I don't have objections in general, conceptually
this change makes sense to me. But I left two minor comments in the pull
request.
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13178) Spark job gets stuck indefinitely while trying to fetch data from ignite cluster using thin client
Ameer Basha Pattan created IGNITE-13178:
---
Summary: Spark job gets stuck indefinitely while trying to fetch
data from ignite cluster using thin client
Key: IGNITE-13178
URL: https://issues.apache.org/jira/browse/IGNITE-13178
Project: Ignite
Issue Type: Bug
Components: cache, clients, thin client
Reporter: Ameer Basha Pattan
Attachments: IgniteHelper.java
We are trying to use ignite as in-memory distributed cache and put data inside
cache using spark job.
We tried using thin client to fetch data from cache.
// we are using ThreadLocal to stop creating too many client instances.
private static final ThreadLocal igniteClientContext = new
ThreadLocal<>();
//Thin client creation
public static IgniteClient getIgniteClient(String[] address) \{
if(igniteClientContext.get() == null) { ClientConfiguration clientConfig =
null; if(cfg == null) { clientConfig = new
ClientConfiguration().setAddresses(address); } else \{ clientConfig = cfg; }
IgniteClient igniteClient = Ignition.startClient(clientConfig);
logger.info("igniteClient initialized ");
igniteClientContext.set(igniteClient); } return igniteClientContext.get(); }
>From spark code, I'm trying to create instance of ignite thin client and
>create cache object.
{{val address = config.igniteServers.split(",") // config.igniteServers
="10.xx.xxx.xxx:10800,10.xx.xx.xxx:10800"}}
{{}}
Below code will be called from spark executor. We will be processing set or
records in each executor and we are only reading data from cache and comparing
with currently processing record. If it is already present in cache, we will
ignore otherwise we will consume it.
{{}}
{{val cacheCfg = new ClientCacheConfiguration()
.setName(PNR_CACHE)
.setCacheMode(CacheMode.REPLICATED)
.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC)
.setDefaultLockTimeout(3)
val igniteClient = IgniteHelper.getIgniteClient(address)
val cache : ClientCache[Long, Boolean] =
igniteClient.getOrCreateCache(cacheCfg);}}
{{}}
{{Job is running fine for couple of hours and it gets stuck with below
exception indefinitely.}}
{{}}
{{org.apache.ignite.client.ClientConnectionException: Ignite cluster is
unavailable
[sock=Socket[addr=hdpct2ldap01g02.hadoop.sgdcprod..com/10.xx.xx.xx,port=10800,localport=20214]]
at
org.apache.ignite.internal.client.thin.TcpClientChannel.handleIOError(TcpClientChannel.java:499)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.handleIOError(TcpClientChannel.java:491)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.access$100(TcpClientChannel.java:92)
at
org.apache.ignite.internal.client.thin.TcpClientChannel$ByteCountingDataInput.read(TcpClientChannel.java:538)
at
org.apache.ignite.internal.client.thin.TcpClientChannel$ByteCountingDataInput.readInt(TcpClientChannel.java:572)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.processNextResponse(TcpClientChannel.java:272)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:234)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:171)
at
org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:160)
at
org.apache.ignite.internal.client.thin.ReliableChannel.request(ReliableChannel.java:187)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.getOrCreateCache(TcpIgniteClient.java:124)
at
com..eda.pnr.PnrApplication$$anonfun$2$$anonfun$apply$4.apply(PnrApplication.scala:305)
at
com..eda.pnr.PnrApplication$$anonfun$2$$anonfun$apply$4.apply(PnrApplication.scala:297)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at
org.apache.spark.storage.memory.MemoryStore.putIteratorAsValues(MemoryStore.scala:217)
at
org.apache.spark.storage.BlockManager$$anonfun$doPutIterator$1.apply(BlockManager.scala:1094)
at
org.apache.spark.storage.BlockManager$$anonfun$doPutIterator$1.apply(BlockManager.scala:1085)
at org.apache.spark.storage.BlockManager.doPut(BlockManager.scala:1020)
at org.apache.spark.storage.BlockManager.doPutIterator(BlockManager.scala:1085)
at org.apache.spark.storage.BlockManager.getOrElseUpdate(BlockManager.scala:811)
at org.apache.spark.rdd.RDD.getOrCompute(RDD.scala:335)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:286)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
at org.apache.spark.scheduler.Task.run(Task.scala:109)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:381)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.SocketException: Connection timed out (Read failed)
at java.net.SocketInputStream.socketRead0(Native
[jira] [Comment Edited] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142834#comment-17142834
]
Ivan Daschinskiy edited comment on IGNITE-13042 at 6/23/20, 11:36 AM:
--
[~isapego] Ah, I see. So everything is ok, thank you. No objections to merge
from me.
was (Author: ivandasch):
[~isapego] Ah, I see. So everything is ok, thank you.
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13134) Fix connection recovery timout.
[ https://issues.apache.org/jira/browse/IGNITE-13134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13134: -- Attachment: IGNITE-130134-patch.patch > Fix connection recovery timout. > --- > > Key: IGNITE-13134 > URL: https://issues.apache.org/jira/browse/IGNITE-13134 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Attachments: IGNITE-130134-patch.patch > > Time Spent: 10m > Remaining Estimate: 0h > > If node experiences connection issues it must establish new connection or > fail within failureDetectionTimeout + connectionRecoveryTimout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13134) Fix connection recovery timout.
[ https://issues.apache.org/jira/browse/IGNITE-13134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13134: -- Attachment: (was: IGNITE-130134-patch.patch) > Fix connection recovery timout. > --- > > Key: IGNITE-13134 > URL: https://issues.apache.org/jira/browse/IGNITE-13134 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Attachments: IGNITE-130134-patch.patch > > Time Spent: 10m > Remaining Estimate: 0h > > If node experiences connection issues it must establish new connection or > fail within failureDetectionTimeout + connectionRecoveryTimout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13134) Fix connection recovery timout.
[ https://issues.apache.org/jira/browse/IGNITE-13134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13134: -- Attachment: IGNITE-130134-patch.patch > Fix connection recovery timout. > --- > > Key: IGNITE-13134 > URL: https://issues.apache.org/jira/browse/IGNITE-13134 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Attachments: IGNITE-130134-patch.patch > > Time Spent: 10m > Remaining Estimate: 0h > > If node experiences connection issues it must establish new connection or > fail within failureDetectionTimeout + connectionRecoveryTimout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142834#comment-17142834
]
Ivan Daschinskiy commented on IGNITE-13042:
---
[~isapego] Ah, I see. So everything is ok, thank you.
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142821#comment-17142821
]
Igor Sapego commented on IGNITE-13042:
--
[~ivandasch] licenses fixed already and suite passes (as visa states):
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_LicensesHeaders/5411515
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142787#comment-17142787
]
Ivan Daschinskiy commented on IGNITE-13042:
---
[~isapego] Cheked odbc tests and thin client tests on Ubuntu 20.04 --
everything is ok.
But i see licence errors -- please, add exclusions for sh scripts in this file
{{parent/pom.xml:964}}
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142753#comment-17142753
]
Igor Sapego commented on IGNITE-13042:
--
Re-generated certificates and keys, added script. [~ivandasch] , can you take a
look?
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142744#comment-17142744
]
Ignite TC Bot commented on IGNITE-13042:
{panel:title=Branch: [pull/7954/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Win x64 / Debug){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=5410974]]
{panel}
[TeamCity *-> Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5410979&buildTypeId=IgniteTests24Java8_RunCpp]
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142722#comment-17142722
]
Sergey Chugunov commented on IGNITE-13012:
--
[~avinogradov], I'll take a look at this today.
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13177) Upgrade Zookeeper version to 3.5.7 or higher
Thomas Landuyt created IGNITE-13177: --- Summary: Upgrade Zookeeper version to 3.5.7 or higher Key: IGNITE-13177 URL: https://issues.apache.org/jira/browse/IGNITE-13177 Project: Ignite Issue Type: Wish Reporter: Thomas Landuyt Hi, To fix the following security vulnerabilities, we would need to upgrade the zookeeper version in ignite. I see these issue are fixed in zookeeper 3.5.7 or higher but these are not included already in latest ignite version. |CVE-2019-20445| |CVE-2019-20444| |CVE-2019-16869| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142707#comment-17142707
]
Alexander Lapin edited comment on IGNITE-12986 at 6/23/20, 8:07 AM:
Hi [~slava.koptilin], LGTM
was (Author: alapin):
Hi [~slava.koptilin] LGTM
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142707#comment-17142707
]
Alexander Lapin commented on IGNITE-12986:
--
Hi [~slava.koptilin] LGTM
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142702#comment-17142702
]
Anton Vinogradov commented on IGNITE-13012:
---
[~vladsz83] Bench shows a huge boost!
[~sergey-chugunov], Going to merge the fix tomorrow in case of no objections
here.
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13176) C++: Remove autotools build after merging CMake
[
https://issues.apache.org/jira/browse/IGNITE-13176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13176:
--
Description: Old autotools build scripts and release steps in {{pom.xml}}
should be removed.
> C++: Remove autotools build after merging CMake
> ---
>
> Key: IGNITE-13176
> URL: https://issues.apache.org/jira/browse/IGNITE-13176
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Trivial
> Fix For: 2.9
>
>
> Old autotools build scripts and release steps in {{pom.xml}} should be
> removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13176) C++: Remove autotools build after merging CMake
Ivan Daschinskiy created IGNITE-13176: - Summary: C++: Remove autotools build after merging CMake Key: IGNITE-13176 URL: https://issues.apache.org/jira/browse/IGNITE-13176 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
