[jira] [Created] (IGNITE-13099) .net thin client - node selection on start up incorrect - wrong node chosen in ClientFailoverSocket GetNextSocket
david created IGNITE-13099: -- Summary: .net thin client - node selection on start up incorrect - wrong node chosen in ClientFailoverSocket GetNextSocket Key: IGNITE-13099 URL: https://issues.apache.org/jira/browse/IGNITE-13099 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.8.1, 2.8 Environment: .net core 3.1 / windows server 2019 / c# Reporter: david To reproduce var cfg = new IgniteClientConfiguration() { Endpoints = new List() { "localhost","ignite01","ignite02","ignite03","ignite04" } }; Ignition.StartClient(cfg) Log show ignite Thin client connecting to "ignite01" and not "localhost" first - the first elment in the array? if Port randes are used: eg: Endpoints = new List() { "localhost:10800..10810","ignite01:10800..10810","ignite02:10800..10810" //snip } }; logs show connecting to localhost:10801 and localhost:10800 is skipped -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [5354234, 5346728] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New test failure in master GridJobServicesAddNodeTest.testServiceDescriptorsJob https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5305934352097646699&branch=%3Cdefault%3E&tab=testDetails No changes in the build *Test with high flaky rate in master BinaryConfigurationTest.TestCodeConfiguration https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2134815735276887535&branch=%3Cdefault%3E&tab=testDetails *Test with high flaky rate in master BinaryConfigurationTest.TestXmlConfiguration https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4488201393739220401&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 12:31:34 01-06-2020
[jira] [Created] (IGNITE-13100) ClassCastException in cache group metrics on client nodes
Alexey Goncharuk created IGNITE-13100: - Summary: ClassCastException in cache group metrics on client nodes Key: IGNITE-13100 URL: https://issues.apache.org/jira/browse/IGNITE-13100 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk The following exception can be observed when reading cache group metrics on client nodes with persistence-enabled config: {code} java.lang.ClassCastException: org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager cannot be cast to org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager at org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.database(CacheGroupMetricsImpl.java:506) at org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.lambda$new$0(CacheGroupMetricsImpl.java:103) at org.apache.ignite.internal.util.lang.GridFunc.lambda$nonThrowableSupplier$3(GridFunc.java:3341) at org.apache.ignite.internal.processors.metric.impl.LongGauge.value(LongGauge.java:45) at org.apache.ignite.spi.metric.LongMetric.getAsString(LongMetric.java:29) {code} The reason is an incomplete check for persistence enabled in {{CacheGroupMetricsImpl}}: we should also check for client nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Re[2]: [DISCUSSION] Ignite.C++ and CMake
Igor, could you please check my PR? пт, 29 мая 2020 г. в 15:28, Ivan Daschinsky : > Thanks you all. Run patch (I've changed some code also) on TC -- all CPP > suites are green (GCC, CLang, Win64) > > пт, 29 мая 2020 г. в 15:02, Zhenya Stanilovsky >: > >> >> >> Ivan besides documentation [1] >> -s no — no works >> -- catch_system_errors =no — works properly well, tests are passed. >> >> boost 1.65 >> >> [1] >> https://www.boost.org/doc/libs/1_65_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/catch_system.html >> >> >Hello! >> > >> >I didn't check tests since I don't develop AI C++, merely use it as user. >> >That's where we should wait for Igor Sapego to check. >> > >> >Regards, >> >-- >> >Ilya Kasnacheev >> > >> > >> >пт, 29 мая 2020 г. в 12:20, Ivan Daschinsky < ivanda...@gmail.com >: >> > >> >> Ilya, thanks a lot! What about tests? I found one flag that must be >> >> supplied to boost.tests. >> >> This flag should fix JVM crash of C++ suites on Linux. >> >> >> >> Zhenya Stanilovsky and me have checked, that without this flag tests >> failed >> >> with SIGSEGV early (boost catch this signal from jvm, but it is ok for >> >> jvm). >> >> Flag is -catch_system_errors=no. I added it to CTest runner. You can >> >> invoke it manually and using make test ARGS="-V" >> >> >> >> >> >> >> >> пт, 29 мая 2020 г. в 11:54, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com >: >> >> >> >> > Hello! >> >> > >> >> > Looks good to me! But we probably also ask Igor to take a look. >> >> > >> >> > Compiled debug and release, without and with odbc, checked running >> thick >> >> > node and ODBC connection on Linux. >> >> > >> >> > Regards, >> >> > -- >> >> > Ilya Kasnacheev >> >> > >> >> > >> >> > чт, 28 мая 2020 г. в 17:31, Ivan Daschinsky < ivanda...@gmail.com >: >> >> > >> >> > > Ok, PR is ready >> >> > > https://issues.apache.org/jira/browse/IGNITE-13078 >> >> > > >> >> > > Build tested on Mac OS X 10.15 and Ubuntu 20.04 with CMake 3.17.2 >> and >> >> > 3.6.1 >> >> > > Unfortunately, I was not able to test on Windows, but principally >> it >> >> > should >> >> > > works, but minor issues are probable. >> >> > > >> >> > > Instruction is attached in PR. >> >> > > Any use reports are welcomed! >> >> > > >> >> > > вт, 26 мая 2020 г. в 18:51, Ivan Daschinsky < ivanda...@gmail.com >> >: >> >> > > >> >> > > > Stephen, looks great! I do mostly the same things in C++ code. >> Thank >> >> > you! >> >> > > > >> >> > > > вт, 26 мая 2020 г. в 18:33, Stephen Darlington < >> >> > > > stephen.darling...@gridgain.com >: >> >> > > > >> >> > > >> Not sure if it’ll help, but I made some changes to get it >> working >> >> on a >> >> > > >> Mac with the current built system. There may be some code worth >> >> > taking. >> >> > > >> >> >> > > >> https://github.com/apache/ignite/pull/4872 < >> >> > > >> https://github.com/apache/ignite/pull/4872 > >> >> > > >> >> >> > > >> Regards, >> >> > > >> Stephen >> >> > > >> >> >> > > >> > On 26 May 2020, at 16:02, Ivan Daschinsky < >> ivanda...@gmail.com > >> >> > > wrote: >> >> > > >> > >> >> > > >> > I appreciate any help, thank you, Ilya. >> >> > > >> > >> >> > > >> > Currently I have a small PR without ticket (link in first >> >> post),but >> >> > I >> >> > > >> > decided not to file a jira issue before discussion. >> >> > > >> > Now I see, that this feature are of great interest to >> community. >> >> So >> >> > I >> >> > > >> file >> >> > > >> > a ticket, test myself on my home laptop (ubuntu 20.04) >> >> > > >> > and add detailed instructions to DEVNOTES.txt in a few days. >> >> > > >> > >> >> > > >> > I would be happy if my someone can follow the instruction and >> >> write >> >> > > >> > possible issues. >> >> > > >> > >> >> > > >> > I will notify about status update in this thread in next few >> days. >> >> > > >> > >> >> > > >> > Thank you all very much for support! >> >> > > >> > >> >> > > >> > >> >> > > >> > вт, 26 мая 2020 г. в 17:50, Ilya Kasnacheev < >> >> > > ilya.kasnach...@gmail.com >> >> > > >> >: >> >> > > >> > >> >> > > >> >> Hello! >> >> > > >> >> >> >> > > >> >> I will assist with checking on Linux if you would contribute >> a >> >> > patch. >> >> > > >> >> Please start with a ticket (or even an IEP maybe?) >> >> > > >> >> >> >> > > >> >> Regards, >> >> > > >> >> -- >> >> > > >> >> Ilya Kasnacheev >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> вт, 26 мая 2020 г. в 16:47, Ivan Daschinsky < >> ivanda...@gmail.com >> >> >: >> >> > > >> >> >> >> > > >> >>> Guys, I will certainly thoroughly test my fix not only >> unices, >> >> but >> >> > > on >> >> > > >> >>> windows too. >> >> > > >> >>> And I will describe it very thoroughly. >> >> > > >> >>> >> >> > > >> >>> When I was C++ developer (more than 10 years ago), I have >> not >> >> any >> >> > > >> trouble >> >> > > >> >>> at all with CMake and Visual Studio 2005. >> >> > > >> >>> Everything works and works good. Moreover, you can build >> with >> >> > NMake, >> >> > > >> >>> msbuild and generate solutions for dev
Re: [DISCUSSION] IEP-47 Native persistence defragmentation
Hi Ivan, I have an idea about suggested maintenance mode. First of all, I agree with your ideas about discovery restrictions: node should not join topology when performing defragmentation. At the same time I haven't heard about requests for this mode from users, so we don't know much about possible requirements. So I suggest to implement it in a pragmatical way: instead of inventing (unknown in reality) user scenarios lets develop minimal but yet well-designed functionality that suites our case. If we constrain our implementation with reasonable set of restrictions that's OK. So my idea is the following: to transit a node to maintenance user has to send special command to the node (e.g. with new command in control.sh utility or via JMX interface). Node saves maintenance request in local metastorage and waits for restart. User has to manually restart that node in order to finish moving it to maintenance mode. When node restarts and finds maintenance request it creates special type of discovery SPI that will not try to join topology at all yet node is able to start all necessary components and APIs like REST processor or JMX interface. When in maintenance, we'll be able to do defragmentation safely and remove maintenance request from metastorage only when it is completed (with all fault-tolerance logic in mind). As we don't have a mechanism (like watcher) to perform a "safe restart" (by safe I mean Ignite restart without OS-level process restart) we cannot finish maintenance mode without another manual restart but I think it is a reasonable restriction as maintenance mode shouldn't be an every-day routine and will be used quite rare. What do you think about it? On Tue, May 26, 2020 at 5:58 PM Ivan Bessonov wrote: > Hello Igniters, > > I'd like to discuss this new IEP with you: [1]. The main idea is to have a > procedure that relocates > pages to the top of the file as compact as possible which allows us to > trim the file and increase its > fill-factor. It will be configured manually and executed after the restart, > but before node joins > topology (it means any load would be impossible during defragmentation). It > is described in detail > in the IEP itself, please read it. This topic was also previously discussed > here on dev-list in [2]. > > Here I would like to list a few moments that are not as clear and require > your opinion. > > - what are your overall thoughts on the IEP? Any concerns? > > - maintenance mode - how do we communicate with the node that's not in > topology? What are >the options? As far as I know, we have no current tools like this. > > - checkpointer refactoring - these changes will involve intensive writing > of pages to the storage. >If we're going to reuse the offheap page model to perform > defragmentation then the >checkpointing mechanism will have to be adapted in some form. >Are you fine with this? Or we need a separate discussion? > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation > [2] > > http://apache-ignite-developers.2346864.n4.nabble.com/How-to-free-up-space-on-disc-after-removing-entries-from-IgniteCache-with-enabled-PDS-td39839.html > > > -- > Sincerely yours, > Ivan Bessonov >
[jira] [Created] (IGNITE-13101) Metastore may leave uncompleted write futures during node stop
Alexey Goncharuk created IGNITE-13101: - Summary: Metastore may leave uncompleted write futures during node stop Key: IGNITE-13101 URL: https://issues.apache.org/jira/browse/IGNITE-13101 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk I've got the following thread-dump (only relevant parts are retained) during one of the teamcity runs: {code} "sys-#103862%baseline.IgniteStableBaselineBinObjFieldsQuerySelfTest0%" #107048 prio=5 os_prio=0 tid=0x7fa2d8009800 nid=0x480d waiting on condition [0x7fa1d1cdc000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304) at org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178) at org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141) at org.apache.ignite.internal.processors.metric.GridMetricManager.remove(GridMetricManager.java:411) at org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.remove(CacheGroupMetricsImpl.java:497) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:512) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCacheGroup(GridCacheProcessor.java:2901) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCacheGroup(GridCacheProcessor.java:2889) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCacheStopRequestOnExchangeDone(GridCacheProcessor.java:2781) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2878) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2431) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3832) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3608) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:3207) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$200(GridDhtPartitionsExchangeFuture.java:154) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2994) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2982) 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.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2982) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1989) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.preprocessSingleMessage(GridCachePartitionExchangeManager.java:524) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1100(GridCachePartitionExchangeManager.java:182) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:407) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:389) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3715) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3694) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java
[jira] [Created] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had closed before.
Sergey Antonov created IGNITE-13102: --- Summary: IgniteCache#isClosed() returns false on server node even if the cache had closed before. Key: IGNITE-13102 URL: https://issues.apache.org/jira/browse/IGNITE-13102 Project: Ignite Issue Type: Bug Affects Versions: 2.8.1, 2.8 Reporter: Sergey Antonov Fix For: 2.9 IgniteCache#isClosed() still returns {{false}} even after {{IgniteCache#close()}}. Only server nodes affect by this problem. Simple reproducer: {code:java} @Test public void test() throws Exception { IgniteEx node = startGrid(0); IgniteCache cache = node.getOrCreateCache(DEFAULT_CACHE_NAME); assertFalse(cache.isClosed()); cache.close(); // java.lang.AssertionError assertTrue(cache.isClosed()); } {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13103) Investigate marshalling errors when changing fields of lambda's capturingClass
Ilya Kasnacheev created IGNITE-13103: Summary: Investigate marshalling errors when changing fields of lambda's capturingClass Key: IGNITE-13103 URL: https://issues.apache.org/jira/browse/IGNITE-13103 Project: Ignite Issue Type: Bug Components: binary, compute Affects Versions: 2.8.1 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Trying to execute static lambda whose outer type's fields changed leads to the following error: {code} Exception in thread "main" class org.apache.ignite.IgniteException: Remote job threw user exception (override or implement ComputeTask.result(..) method if you would like to have automatic failover for this exception): Failed to serialize object [typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4] at org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:102) at org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1062) at org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1055) at org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7037) at org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1055) at org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:862) 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:829) at org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:497) at org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:244) at org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:216) at org.apache.ignite.internal.IgniteComputeImpl.runAsync0(IgniteComputeImpl.java:702) at org.apache.ignite.internal.IgniteComputeImpl.run(IgniteComputeImpl.java:678) at com.gridgain.deployer.c.ComputeCallerStarter.start(ComputeCallerStarter.java:19) at com.gridgain.deployer.c.ComputeCallerStarter.main(ComputeCallerStarter.java:13) Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to serialize object [typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4] at org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:853) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152) at org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251) at org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:84) at org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:57) at org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10386) at org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1397) at org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:664) at org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:536) ... 9 more Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to serialize object [typeName=java.lang.invoke.SerializedLambda] at org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:853) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:227) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152) at org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:524) at org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObject(BinaryWriterExImpl.java:1503) at org.apache
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
I think that [1] and [2] should not be changed, because we can kill another client code in this jvm. I suggest for these purposes to create a new [3] which will be like [1] but with a call [4] after node stop. Objections or comments? [1] - org.apache.ignite.failure.StopNodeFailureHandler [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler [3] - org.apache.ignite.failure.FailureHandler [4] - java.lang.System#exit 25.05.2020, 22:09, "Dmitriy Pavlov" : > It seems reasonable to me. Also I would like to propose adding value of > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > Dev ops/admins/anyone who admins Ignite may want to know it's value without > going to Java code. > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky : > >> Thank you Sergey, as for me — very useful proposal huge +1 here. >> >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < >> antonovserge...@gmail.com>: >> > >> >I've created the Ignite ticket for this improvement [1]. >> > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 >> > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < antonovserge...@gmail.com >: >> > >> >> Hello, Igniters! >> >> >> >> I'd like to discuss behaviour of Ignite process exit code if the node >> was >> >> stopped by failure handler [1][2]. At the moment ignite process returns >> >> exit code 0 after the stop in all scenarios, except runtime halt by >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] >> >> >> >> My proposal: always finish Ignite process with code [3], if a node was >> >> stopped by FH. It could be helpful for administration purposes, you can >> >> distinguish normal node stop from node stop by FH on OS level. >> >> >> >> WDYT? >> >> >> >> [1] >> >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html >> >> >> >> [2] >> >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html >> >> >> >> [3] >> >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE >> >> -- >> >> BR, Sergey Antonov >> >> >> > >> >-- >> >BR, Sergey Antonov >> >
[jira] [Created] (IGNITE-13104) Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
Alexey Kuznetsov created IGNITE-13104: - Summary: Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code Key: IGNITE-13104 URL: https://issues.apache.org/jira/browse/IGNITE-13104 Project: Ignite Issue Type: Improvement Components: springdata Affects Versions: 2.8.1 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.9 {code} /** {@inheritDoc} */ @Override public void deleteAllById(Iterable ids) { if (ids instanceof Set) cache.removeAll((Set)ids); if (ids instanceof Collection) cache.removeAll(new HashSet<>((Collection)ids)); TreeSet keys = new TreeSet<>(); for (ID id : ids) keys.add(id); cache.removeAll(keys); } {code} As you can see cache.removeAll may be executed THREE times in some situations. Also this method can throw ClassCast exception if ids collection contains objects that are not implement Comparable interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13105) Spring data 2.0 IgniteRepositoryQuery#transformQueryCursor contains cursor leak
Alexey Kuznetsov created IGNITE-13105: - Summary: Spring data 2.0 IgniteRepositoryQuery#transformQueryCursor contains cursor leak Key: IGNITE-13105 URL: https://issues.apache.org/jira/browse/IGNITE-13105 Project: Ignite Issue Type: Improvement Components: springdata Affects Versions: 2.8.1 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.9 This code produce cursor leak in RunningQueryManager: If result set contains one ore more rows. {code} case ONE_VALUE: Iterator iter = qryIter.iterator(); if (iter.hasNext()) return iter.next().get(0); return null; {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
Hello, Kirill! I'd prefer to don't create a new implementation of a failure handler. We already have 4 different failure handlers. We will have 6 FH (StopNodeFH with exit code, StopNodeOrHaltFH with exit code), if we go your way. It won't make our product simpler and easier. I think, we must notify a user if the cluster node had been stopped by a failure handler. We can't achieve this goal without changing current FH behavior. So I propose to change it and stop the process with KILL_EXIT_CODE. But it would be nice if users will have a flag for avoiding process stop after a node failure. We can introduce a new JVM option or FH parameter for that reason. Of course, we must highlight this change in the release notes. пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл : > I think that [1] and [2] should not be changed, because we can kill > another client code in this jvm. > I suggest for these purposes to create a new [3] which will be like [1] > but with a call [4] after node stop. > Objections or comments? > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > [3] - org.apache.ignite.failure.FailureHandler > [4] - java.lang.System#exit > > 25.05.2020, 22:09, "Dmitriy Pavlov" : > > It seems reasonable to me. Also I would like to propose adding value of > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > without > > going to Java code. > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > : > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > >> > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > >> antonovserge...@gmail.com>: > >> > > >> >I've created the Ignite ticket for this improvement [1]. > >> > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > >> > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > antonovserge...@gmail.com >: > >> > > >> >> Hello, Igniters! > >> >> > >> >> I'd like to discuss behaviour of Ignite process exit code if the > node > >> was > >> >> stopped by failure handler [1][2]. At the moment ignite process > returns > >> >> exit code 0 after the stop in all scenarios, except runtime halt by > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > >> >> > >> >> My proposal: always finish Ignite process with code [3], if a node > was > >> >> stopped by FH. It could be helpful for administration purposes, you > can > >> >> distinguish normal node stop from node stop by FH on OS level. > >> >> > >> >> WDYT? > >> >> > >> >> [1] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > >> >> > >> >> [2] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > >> >> > >> >> [3] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > >> >> -- > >> >> BR, Sergey Antonov > >> >> > >> > > >> >-- > >> >BR, Sergey Antonov > >> > > -- BR, Sergey Antonov
Re: [DISCUSSION] Key and Value fields with same name and SQL DML
Hi Alexey, Let me answer the second question first How would you change ICache interface which has this member? We will keep the key-value interface at least for backward compatibility. Plus, it might be preferred by those who use caching APIs only. So, this method will stay as-is. What whould be returned from the query like this "select > _key from cache" if we don't know the type of the key? ExpandoObject, > Tuple, > BinaryObject? I would go for BinaryObject. Also, I would review if we really need to make "_key" visible for application developers. - Denis On Tue, May 26, 2020 at 4:22 AM Alexey Sasov wrote: > Hello. Looks good. What whould be returned from the query like this "select > _key from cache" if we don't know the type of the key? ExpandoObject, > Tuple, > BinaryObject? How would you change ICache interface which has this member? > > /// Queries cache. > /// Query. > /// Cursor. > IQueryCursor> Query(QueryBase qry); > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
maintenance on repository.apache.org - may have broken an ignite staging repository
Hello ignite folks. I noticed that there is a staging repo on repository.apache.org, it's url is here: https://repository.apache.org/content/repositories/orgapacheignite-1249 I had to address some data integrity issues on repository.apache.org and that staging repo may have been a casualty. Likely the easiest fix would be to drop that repository and stage a new build. If you have any questions, please let me know. -Wes -- Wes Wannemacher
[jira] [Created] (IGNITE-13106) Java thin client: Race between response and notification for compute tasks
Aleksey Plekhanov created IGNITE-13106: -- Summary: Java thin client: Race between response and notification for compute tasks Key: IGNITE-13106 URL: https://issues.apache.org/jira/browse/IGNITE-13106 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.9 Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Java thin client {{ClientCompute.execute()}} method can hang due to race between processing of COMPUTE_TASK_EXECUTE response and COMPUTE_TASK_FINISHED notification. These messages are strongly ordered on the server-side. But on the client-side response and notification are processed by different threads. If notification will be processed before response, task future will never be completed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Phani Introduction
Hello, I am Phani, currently working as an Engineer; interested in distributed systems, caches, persistent stores. I am looking forward to be part of this wonderful Ignite community and contribute. My jira user: psadusumilli. Please let me know if you need any information to add me to the group. -- Thank you Phani S Adusumilli