[jira] [Created] (IGNITE-8787) Striped Executor thread failure is not processed by IgniteFailureProcessor
Andrew Medvedev created IGNITE-8787: --- Summary: Striped Executor thread failure is not processed by IgniteFailureProcessor Key: IGNITE-8787 URL: https://issues.apache.org/jira/browse/IGNITE-8787 Project: Ignite Issue Type: Bug Reporter: Andrew Medvedev Attachments: after.jstack, before.jstack org.apache.ignite.internal.util.StripedExecutor.Stripe#run currently does not invoke IgniteFailureProcessor upon thread death. This can lead to dying all striped threads on a running node. see jstacks attach before and after killing all striped threads (via JMX). If striped executor threads are considered critical, they should be processed by IgniteFailureProcessor as well -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Ignite 2.6 emergency release suggestion
Hi, Fix for IGNITE-8722 (https://issues.apache.org/jira/browse/IGNITE-8722) is ready. Diff https://git1-us-west.apache.org/repos/asf?p=ignite.git=search=refs%2Fheads%2Fignite-8722=commit=IGNITE-8722 TC looks good for me. https://ci.ignite.apache.org/viewLog.html?buildId=1385195=buildResultsDiv=IgniteTests24Java8_JavaClient I'm ready to merge to master and 2.6 branches. Please approve. -- Alexey Kuznetsov
Re: Best Effort Affinity for thin clients
Pavel, Most likely the client will be pulling the partitioning map periodically. If the local map is outdated, it won't be a big deal because a server node that receives a request: - can redirect it to a map that owns a partition - will add an updated partition map to the client's response or will turn a special flag in the response suggesting the client do that manually. Igor, is this what you're suggesting? -- Denis On Wed, Jun 13, 2018 at 11:31 AM Pavel Tupitsyn wrote: > Hi Igor, > > How can we invoke the affinity function on the client, if we don't have the > implementation at hand? > Am I missing something? > > Thanks, > Pavel > > > On Wed, Jun 13, 2018 at 5:34 PM, Igor Sapego wrote: > > > Hi, Igniters, > > > > Currently, I'm working on the thin C++ client implementation. > > As you may already know, there is an issue with latency in our > > thin clients, which also can result in performance issues (you > > can see the "About Ignite Thin client performance" thread on > > user list). > > > > So, how about we implement some kind of "Best Effort Affinity" > > for our thin clients? In my opinion, this could be possible and > > may improve mean latency when using thin clients dramatically. > > > > The scenario is following: > > 1. Thin client connects to one of the node from the provided > > address list, just as now. > > 2. When user create instance of CacheClient, thin client > > requests partition mapping for the cache. > > 3. Client establishes connections to nodes, which are both in the > > list, provided by user and in a server node response. > > 4. When user makes put/get/some other cache operation, > > thin client makes the best effort to send the request to the node, > > which stores the data. > > 5. To update partition mapping, thin client can provide public API, > > or do it with some timeout. Also, we can add "miss" flag to cache > > operation response, which whill indicate, that operation was not > > local for the server node and which thin client can use to > > understand, that partition mapping has changed to request server > > node for an update. > > > > What do you think? > > > > Best Regards, > > Igor > > >
[jira] [Created] (IGNITE-8786) session.removeAttribute does not work as expected
Dana Shaw created IGNITE-8786: - Summary: session.removeAttribute does not work as expected Key: IGNITE-8786 URL: https://issues.apache.org/jira/browse/IGNITE-8786 Project: Ignite Issue Type: Bug Affects Versions: 2.5, 2.4 Environment: Java 8, Java 9, Java 10 Ignite 2.4 and Ignite 2.5 Reporter: Dana Shaw Sample project: [https://github.com/daynok/ignite-webapp] What I'm noticing is that session.removeAttribute doesn't really remove the attribute, it only sets the value to null. I'm not sure if this is a setup issue on my end or what. I thought this might be related to jsf, removed jsf and the issue persists. Thanks in advance and please help! dshaw The closest issue that I could find to my particular issue was: [https://github.com/apache/ignite/pull/2243] I patched my local ignite repo with #2243 , redeployed to tomcat and 2 ignite nodes but am seeing the same issue. The closest issue that I could find to my particular issue was: [https://github.com/apache/ignite/pull/2243] My setup (client/server): - Ignite 2.5.0 (2 node cluster) - Apache Tomcat 7 - Java 9 tomcat setenv.sh #!/bin/sh export JAVA_HOME=/opt/java/jdk-10.0.1 export PATH=$JAVA_HOME/bin:$PATH export CATALINA_OPTS="--add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED --add-modules java.xml.bind" export CATALINA_HOME=/opt/apache/apache-tomcat-7.0.86_node # Config use by 3 tomcat notes client-config.xml (used by tomcat 7) http://www.springframework.org/schema/beans]" xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance]" xmlns:util="[http://www.springframework.org/schema/util]" xsi:schemaLocation=" [http://www.springframework.org/schema/beans] [http://www.springframework.org/schema/beans/spring-beans.xsd] [http://www.springframework.org/schema/util] [http://www.springframework.org/schema/util/spring-util.xsd];> 172.24.2.156:47500..47509 172.24.3.28:47500..47509 # Config use by 2 ignite nodes http://www.springframework.org/schema/beans]" xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance]" xmlns:util="[http://www.springframework.org/schema/util]" xsi:schemaLocation=" [http://www.springframework.org/schema/beans] [http://www.springframework.org/schema/beans/spring-beans.xsd] [http://www.springframework.org/schema/util] [http://www.springframework.org/schema/util/spring-util.xsd];> 172.24.2.156:47500..47509 172.24.3.28:47500..47509 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Best Effort Affinity for thin clients
Hi Igor, How can we invoke the affinity function on the client, if we don't have the implementation at hand? Am I missing something? Thanks, Pavel On Wed, Jun 13, 2018 at 5:34 PM, Igor Sapego wrote: > Hi, Igniters, > > Currently, I'm working on the thin C++ client implementation. > As you may already know, there is an issue with latency in our > thin clients, which also can result in performance issues (you > can see the "About Ignite Thin client performance" thread on > user list). > > So, how about we implement some kind of "Best Effort Affinity" > for our thin clients? In my opinion, this could be possible and > may improve mean latency when using thin clients dramatically. > > The scenario is following: > 1. Thin client connects to one of the node from the provided > address list, just as now. > 2. When user create instance of CacheClient, thin client > requests partition mapping for the cache. > 3. Client establishes connections to nodes, which are both in the > list, provided by user and in a server node response. > 4. When user makes put/get/some other cache operation, > thin client makes the best effort to send the request to the node, > which stores the data. > 5. To update partition mapping, thin client can provide public API, > or do it with some timeout. Also, we can add "miss" flag to cache > operation response, which whill indicate, that operation was not > local for the server node and which thin client can use to > understand, that partition mapping has changed to request server > node for an update. > > What do you think? > > Best Regards, > Igor >
[GitHub] ignite pull request #4185: IGNITE-7700 SQL system view for list of nodes
GitHub user alex-plekhanov opened a pull request: https://github.com/apache/ignite/pull/4185 IGNITE-7700 SQL system view for list of nodes You can merge this pull request into a Git repository by running: $ git pull https://github.com/alex-plekhanov/ignite ignite-7700 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4185.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4185 commit f65eca5c41eeda35960d8d010b2640fdbf98bf46 Author: Aleksey Plekhanov Date: 2018-06-13T14:52:25Z IGNITE-7700 SQL system view for list of nodes ---
[jira] [Created] (IGNITE-8785) Node may hang indefinitely in CONNECTING state during cluster segmentation
Pavel Kovalenko created IGNITE-8785:
---
Summary: Node may hang indefinitely in CONNECTING state during
cluster segmentation
Key: IGNITE-8785
URL: https://issues.apache.org/jira/browse/IGNITE-8785
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Fix For: 2.6
Affected test:
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest#testTopologyValidatorWithCacheGroup
Node hangs with following stacktrace:
{noformat}
"grid-starter-testTopologyValidatorWithCacheGroup-22" #117619 prio=5 os_prio=0
tid=0x7f17dd19b800 nid=0x304a in Object.wait() [0x7f16b19df000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:931)
- locked <0x000705ee4a60> (a java.lang.Object)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:373)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1948)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:915)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1739)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1046)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
- locked <0x000705995ec0> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
at
org.apache.ignite.testframework.junits.GridAbstractTest$3.call(GridAbstractTest.java:742)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{noformat}
It seems that node never receives acknowledgment from coordinator.
There were some failure before:
{noformat}
[org.apache.ignite:ignite-core] [2018-06-10 04:59:18,876][WARN
][grid-starter-testTopologyValidatorWithCacheGroup-22][IgniteCacheTopologySplitAbstractTest$SplitTcpDiscoverySpi]
Node has not been connected to topology and will repeat join process. Check
remote nodes logs for possible error messages. Note that large topology may
require significant time to start. Increase 'TcpDiscoverySpi.networkTimeout'
configuration property if getting this message on the starting nodes
[networkTimeout=5000]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4184: IGNITE-8386
GitHub user alexpaschenko opened a pull request: https://github.com/apache/ignite/pull/4184 IGNITE-8386 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8386 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4184.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4184 commit ce3de793e46e3f77dadf44643fd7e5054b8f4fa3 Author: Alexander Paschenko Date: 2018-05-14T17:38:47Z IGNITE-8384 First steps commit 03617740ab06296558bd30b3e4bdcb79781f12b1 Author: Alexander Paschenko Date: 2018-05-16T17:37:41Z IGNITE-8384 Test fixes. commit 6a3bd7e97741301d55d309d2fb9ad1b7fc2ca4fc Author: Alexander Paschenko Date: 2018-05-18T17:09:49Z Test fixes commit f5b75db8430a63024719f2f25c4f98fa2f1b1348 Author: Alexander Paschenko Date: 2018-05-29T12:51:54Z Correct check for exhausted indexes. commit d47caf7bd55fba83d8d9c27495678655a0750b82 Author: Alexander Paschenko Date: 2018-05-29T16:15:59Z Don't rely on links on update commit 42b9bac6bd3c415cd7e534bdf347c5971d60b0a0 Author: Alexander Paschenko Date: 2018-05-29T17:15:02Z Merge remote-tracking branch 'apache/master' into ignite-8384 commit ad3f6f11b4e5c31b8eb1d84c02dafd6b1adc71ba Author: Alexander Paschenko Date: 2018-05-30T15:23:44Z Test fix commit 8a8c906d918c6846a724379308f966a7a23d7df1 Author: Alexander Paschenko Date: 2018-06-01T18:08:04Z Tests fix commit f1d7fbbc886ea30904040e9796cfeec16046f449 Author: Alexander Paschenko Date: 2018-06-01T18:16:07Z Minors commit a3331b96f45683f88b500aec013ad429799ce564 Author: Alexander Paschenko Date: 2018-06-01T18:27:45Z Revert "Minors" This reverts commit f1d7fbb commit 563f1ab8527d38902eeb697bf6ebf932930ba289 Author: Alexander Paschenko Date: 2018-06-01T18:44:59Z Fix? commit 5d8d8369ee435812b6f4058efe03be5cf840432b Author: Alexander Paschenko Date: 2018-06-04T12:44:14Z PK comparison fix. commit 934f7205bc15e20df50e515ef4d29c32435a8bc4 Author: Alexander Paschenko Date: 2018-06-04T12:45:29Z Merge remote-tracking branch 'apache/master' into ignite-8384 commit 5741ce50db6c1020dbfd7c4187b80a16874d2e36 Author: Alexander Paschenko Date: 2018-06-04T12:51:21Z Minors commit 405135d1c9e539e54181b2c712db0caf659e9c96 Author: Alexander Paschenko Date: 2018-06-04T13:56:02Z Minor commit 9f06e2ec50d18aa8cc3a053d2636329447744677 Author: Alexander Paschenko Date: 2018-06-04T14:56:02Z Minor commit bd87b61fc434eb0a0bf26981581a72426d82a3ba Author: Alexander Paschenko Date: 2018-06-06T13:11:52Z Non-inline idxs fix commit f7a4a42d1b7e2f1105f734c6aeae30d14449b422 Author: Alexander Paschenko Date: 2018-06-06T13:12:47Z Merge remote-tracking branch 'apache/master' into ignite-8384 commit 244d1243d8e8303b2e39788ddcb6d1a05ec0b5de Author: Alexander Paschenko Date: 2018-06-06T15:30:16Z Restore. commit 2696eb87af15b4591a724ea85c5cf99ba8924ff9 Author: Alexander Paschenko Date: 2018-06-08T18:58:39Z Index migration test commit b6273d303ec5e84c550dba980c0b080ef48c7535 Author: Alexander Paschenko Date: 2018-06-09T11:39:52Z Merge remote-tracking branch 'apache/master' into ignite-8384 commit 9fd0fabab0585727f5afd7ff4d55ffa2b00c7c64 Author: devozerov Date: 2018-06-09T13:17:39Z Merge branch 'master' into ignite-8384 commit fb32f2389c60141fa5a27e5b0c3706c959ada7f0 Author: devozerov Date: 2018-06-09T14:19:35Z Minors. commit ad9c692ab99dd68e368cf1bee927b0bf0065a15c Author: devozerov Date: 2018-06-09T14:20:29Z Merge remote-tracking branch 'upstream/ignite-8384' into ignite-8384 commit 93b57df524e19c771127766ca9c68fe67ac77109 Author: Alexander Paschenko Date: 2018-06-09T17:37:03Z IGNITE-8386 Contd commit a9d65d48bcee042678aeb2e00ffc51c31179cf36 Author: Alexander Paschenko Date: 2018-06-13T15:52:31Z JDBC test fixes commit 61b64a2011d16a69d7d589cf11766a4452e4a296 Author: Alexander Paschenko Date: 2018-06-13T15:53:54Z Merge remote-tracking branch 'apache/master' into ignite-8386 commit e0a366a3a85154790a929e88f960c6e65ff2a76f Author: Alexander Paschenko Date: 2018-06-13T16:31:36Z Merge remote-tracking branch 'origin/ignite-8384' into ignite-8386 ---
[jira] [Created] (IGNITE-8784) Deadlock during simultaneous client reconnect and node stop
Pavel Kovalenko created IGNITE-8784:
---
Summary: Deadlock during simultaneous client reconnect and node
stop
Key: IGNITE-8784
URL: https://issues.apache.org/jira/browse/IGNITE-8784
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Fix For: 2.6
{noformat}
[18:48:22,665][ERROR][tcp-client-disco-msg-worker-#467%client%][IgniteKernal%client]
Failed to reconnect, will stop node
class org.apache.ignite.IgniteException: Failed to wait for local node joined
event (grid is stopping).
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.localJoin(GridDiscoveryManager.java:2193)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:583)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedContext.onReconnected(GridCacheSharedContext.java:396)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onReconnected(GridCacheProcessor.java:1159)
at
org.apache.ignite.internal.IgniteKernal.onReconnected(IgniteKernal.java:3915)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:830)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2423)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2402)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:2047)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1896)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1788)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to wait for
local node joined event (grid is stopping).
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.onKernalStop0(GridDiscoveryManager.java:1657)
at
org.apache.ignite.internal.managers.GridManagerAdapter.onKernalStop(GridManagerAdapter.java:652)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2218)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2166)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2551)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:372)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1128)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
at
org.gridgain.grid.internal.processors.cache.database.IgniteDbSnapshotNotStableTopologiesTest.afterTest(IgniteDbSnapshotNotStableTopologiesTest.java:250)
at
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:492)
at junit.framework.TestCase.runBare(TestCase.java:146)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
Re: IGNITE-4188, savepoints with atomic cache?
+1 to Eduard. It's a reasonable change, but we can't just break working code of all the guys that access atomic caches in their transactions. If we try, we will end up with another emergency release. Best Regards, Ivan Rakov On 13.06.2018 19:13, Eduard Shangareev wrote: Guys, I believe, that it's not the case when we should change default behaviour. So, #1 and make it default in 3.0. On Wed, Jun 13, 2018 at 6:46 PM, Dmitrii Ryabov wrote: Vote for #2. I think no one will change this defaults in configuration in #1. 2018-06-13 18:29 GMT+03:00 Anton Vinogradov : Vote for #2 since it can shed light on hidden bug at production. ср, 13 июн. 2018 г. в 18:10, Alexey Goncharuk < alexey.goncha...@gmail.com : Igniters, Bumping up this discussion. The fix has been implemented and it is fine from the technical point of view, but since the fix did not make it to the Ignite 2.0, the implemented fix [1] now will be a breaking change for current Ignite users. I see the following options: 1) Have the fix merged, but do not change the defaults - atomic caches will still be allowed in transactions by default and only configuration change will make Ignite throw exceptions in this case 2) Have the fix merged as is and describe this change in the release notes 3) Postpone the fix until Ignite 3.0 I would vote for option #1 and change only the defaults in Ignite 3.0. Thoughts? [1] https://issues.apache.org/jira/browse/IGNITE-2313 ср, 5 апр. 2017 г. в 22:53, Дмитрий Рябов : IGNITE-2313 done, can you review it? PR: https://github.com/apache/ignite/pull/1709/files JIRA: https://issues.apache.org/jira/browse/IGNITE-2313 CI: http://ci.ignite.apache.org/viewType.html?buildTypeId= IgniteTests_RatJavadoc_IgniteTests=pull%2F1709% 2Fhead=buildTypeStatusDiv 2017-03-29 20:58 GMT+03:00 Denis Magda : Sorry, I get lost in tickets. Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes this change. — Denis On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов < somefire...@gmail.com> wrote: Savepoints marked for 2.1, exceptions for 2.0. Do you want me to make exceptions first? 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов : Finish savepoints or flag for atomic operations? Not sure about savepoints. Exceptions - yes. https://issues.apache. org/jira/browse/IGNITE-2313 isn't it? 2017-03-29 2:12 GMT+03:00 Denis Magda : If we want to make the exception based approach the default one then the task has to be released in 2.0. Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by the code freeze data (April 14)? — Denis On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan < dsetrak...@apache.org> wrote: On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin < sergi.vlady...@gmail.com> wrote: I think updating an Atomic cache from within a transaction perfectly makes sense. For example for some kind of operations logging and so forth. Still I agree that this can be error prone and forbidden by default. I agree with Yakov that by default we should throw an exception and have some kind of flag (on cache or on TX?) to be able to explicitly enable this behavior. Agree, this sounds like a good idea.
Re: IGNITE-4188, savepoints with atomic cache?
Guys, I believe, that it's not the case when we should change default behaviour. So, #1 and make it default in 3.0. On Wed, Jun 13, 2018 at 6:46 PM, Dmitrii Ryabov wrote: > Vote for #2. I think no one will change this defaults in configuration in > #1. > > 2018-06-13 18:29 GMT+03:00 Anton Vinogradov : > > > Vote for #2 since it can shed light on hidden bug at production. > > > > ср, 13 июн. 2018 г. в 18:10, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > Igniters, > > > > > > Bumping up this discussion. The fix has been implemented and it is fine > > > from the technical point of view, but since the fix did not make it to > > the > > > Ignite 2.0, the implemented fix [1] now will be a breaking change for > > > current Ignite users. > > > > > > I see the following options: > > > 1) Have the fix merged, but do not change the defaults - atomic caches > > will > > > still be allowed in transactions by default and only configuration > change > > > will make Ignite throw exceptions in this case > > > 2) Have the fix merged as is and describe this change in the release > > notes > > > 3) Postpone the fix until Ignite 3.0 > > > > > > I would vote for option #1 and change only the defaults in Ignite 3.0. > > > > > > Thoughts? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-2313 > > > > > > ср, 5 апр. 2017 г. в 22:53, Дмитрий Рябов : > > > > > > > IGNITE-2313 done, can you review it? > > > > > > > > PR: https://github.com/apache/ignite/pull/1709/files > > > > JIRA: https://issues.apache.org/jira/browse/IGNITE-2313 > > > > CI: http://ci.ignite.apache.org/viewType.html?buildTypeId= > > > > IgniteTests_RatJavadoc_IgniteTests=pull%2F1709% > > > > 2Fhead=buildTypeStatusDiv > > > > > > > > 2017-03-29 20:58 GMT+03:00 Denis Magda : > > > > > > > > > Sorry, I get lost in tickets. > > > > > > > > > > Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes > this > > > > > change. > > > > > > > > > > — > > > > > Denis > > > > > > > > > > > On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов < > somefire...@gmail.com> > > > > > wrote: > > > > > > > > > > > > Savepoints marked for 2.1, exceptions for 2.0. Do you want me to > > make > > > > > > exceptions first? > > > > > > > > > > > > 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов >: > > > > > > > > > > > >> Finish savepoints or flag for atomic operations? > > > > > >> Not sure about savepoints. Exceptions - yes. > > https://issues.apache. > > > > > >> org/jira/browse/IGNITE-2313 isn't it? > > > > > >> > > > > > >> 2017-03-29 2:12 GMT+03:00 Denis Magda : > > > > > >> > > > > > >>> If we want to make the exception based approach the default one > > > then > > > > > the > > > > > >>> task has to be released in 2.0. > > > > > >>> > > > > > >>> Dmitriy Ryabov, do you think you can finish it (dev, review, > QA) > > by > > > > the > > > > > >>> code freeze data (April 14)? > > > > > >>> > > > > > >>> — > > > > > >>> Denis > > > > > >>> > > > > > On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan < > > > > > dsetrak...@apache.org> > > > > > >>> wrote: > > > > > > > > > > On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin < > > > > > >>> sergi.vlady...@gmail.com> > > > > > wrote: > > > > > > > > > > > I think updating an Atomic cache from within a transaction > > > > perfectly > > > > > >>> makes > > > > > > sense. For example for some kind of operations logging and so > > > > forth. > > > > > >>> Still > > > > > > I agree that this can be error prone and forbidden by > default. > > I > > > > > agree > > > > > >>> with > > > > > > Yakov that by default we should throw an exception and have > > some > > > > kind > > > > > >>> of > > > > > > flag (on cache or on TX?) to be able to explicitly enable > this > > > > > >>> behavior. > > > > > > > > > > > > > > > > > > > > > Agree, this sounds like a good idea. > > > > > >>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > >
[jira] [Created] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
Ivan Rakov created IGNITE-8783:
--
Summary: Failover tests periodically cause hanging of the whole
Data Structures suite on TC
Key: IGNITE-8783
URL: https://issues.apache.org/jira/browse/IGNITE-8783
Project: Ignite
Issue Type: Bug
Components: data structures
Reporter: Ivan Rakov
History of suite runs:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
Chance of suite hang is 18% (based on previous 50 runs).
One of the following failover tests is always a reason of hang:
{noformat}
GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: IGNITE-4188, savepoints with atomic cache?
Vote for #2. I think no one will change this defaults in configuration in #1. 2018-06-13 18:29 GMT+03:00 Anton Vinogradov : > Vote for #2 since it can shed light on hidden bug at production. > > ср, 13 июн. 2018 г. в 18:10, Alexey Goncharuk >: > > > Igniters, > > > > Bumping up this discussion. The fix has been implemented and it is fine > > from the technical point of view, but since the fix did not make it to > the > > Ignite 2.0, the implemented fix [1] now will be a breaking change for > > current Ignite users. > > > > I see the following options: > > 1) Have the fix merged, but do not change the defaults - atomic caches > will > > still be allowed in transactions by default and only configuration change > > will make Ignite throw exceptions in this case > > 2) Have the fix merged as is and describe this change in the release > notes > > 3) Postpone the fix until Ignite 3.0 > > > > I would vote for option #1 and change only the defaults in Ignite 3.0. > > > > Thoughts? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-2313 > > > > ср, 5 апр. 2017 г. в 22:53, Дмитрий Рябов : > > > > > IGNITE-2313 done, can you review it? > > > > > > PR: https://github.com/apache/ignite/pull/1709/files > > > JIRA: https://issues.apache.org/jira/browse/IGNITE-2313 > > > CI: http://ci.ignite.apache.org/viewType.html?buildTypeId= > > > IgniteTests_RatJavadoc_IgniteTests=pull%2F1709% > > > 2Fhead=buildTypeStatusDiv > > > > > > 2017-03-29 20:58 GMT+03:00 Denis Magda : > > > > > > > Sorry, I get lost in tickets. > > > > > > > > Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes this > > > > change. > > > > > > > > — > > > > Denis > > > > > > > > > On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов > > > > wrote: > > > > > > > > > > Savepoints marked for 2.1, exceptions for 2.0. Do you want me to > make > > > > > exceptions first? > > > > > > > > > > 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов : > > > > > > > > > >> Finish savepoints or flag for atomic operations? > > > > >> Not sure about savepoints. Exceptions - yes. > https://issues.apache. > > > > >> org/jira/browse/IGNITE-2313 isn't it? > > > > >> > > > > >> 2017-03-29 2:12 GMT+03:00 Denis Magda : > > > > >> > > > > >>> If we want to make the exception based approach the default one > > then > > > > the > > > > >>> task has to be released in 2.0. > > > > >>> > > > > >>> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) > by > > > the > > > > >>> code freeze data (April 14)? > > > > >>> > > > > >>> — > > > > >>> Denis > > > > >>> > > > > On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan < > > > > dsetrak...@apache.org> > > > > >>> wrote: > > > > > > > > On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin < > > > > >>> sergi.vlady...@gmail.com> > > > > wrote: > > > > > > > > > I think updating an Atomic cache from within a transaction > > > perfectly > > > > >>> makes > > > > > sense. For example for some kind of operations logging and so > > > forth. > > > > >>> Still > > > > > I agree that this can be error prone and forbidden by default. > I > > > > agree > > > > >>> with > > > > > Yakov that by default we should throw an exception and have > some > > > kind > > > > >>> of > > > > > flag (on cache or on TX?) to be able to explicitly enable this > > > > >>> behavior. > > > > > > > > > > > > > > > > > Agree, this sounds like a good idea. > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > >
Re: IGNITE-4188, savepoints with atomic cache?
Vote for #2 since it can shed light on hidden bug at production. ср, 13 июн. 2018 г. в 18:10, Alexey Goncharuk : > Igniters, > > Bumping up this discussion. The fix has been implemented and it is fine > from the technical point of view, but since the fix did not make it to the > Ignite 2.0, the implemented fix [1] now will be a breaking change for > current Ignite users. > > I see the following options: > 1) Have the fix merged, but do not change the defaults - atomic caches will > still be allowed in transactions by default and only configuration change > will make Ignite throw exceptions in this case > 2) Have the fix merged as is and describe this change in the release notes > 3) Postpone the fix until Ignite 3.0 > > I would vote for option #1 and change only the defaults in Ignite 3.0. > > Thoughts? > > [1] https://issues.apache.org/jira/browse/IGNITE-2313 > > ср, 5 апр. 2017 г. в 22:53, Дмитрий Рябов : > > > IGNITE-2313 done, can you review it? > > > > PR: https://github.com/apache/ignite/pull/1709/files > > JIRA: https://issues.apache.org/jira/browse/IGNITE-2313 > > CI: http://ci.ignite.apache.org/viewType.html?buildTypeId= > > IgniteTests_RatJavadoc_IgniteTests=pull%2F1709% > > 2Fhead=buildTypeStatusDiv > > > > 2017-03-29 20:58 GMT+03:00 Denis Magda : > > > > > Sorry, I get lost in tickets. > > > > > > Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes this > > > change. > > > > > > — > > > Denis > > > > > > > On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов > > > wrote: > > > > > > > > Savepoints marked for 2.1, exceptions for 2.0. Do you want me to make > > > > exceptions first? > > > > > > > > 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов : > > > > > > > >> Finish savepoints or flag for atomic operations? > > > >> Not sure about savepoints. Exceptions - yes. https://issues.apache. > > > >> org/jira/browse/IGNITE-2313 isn't it? > > > >> > > > >> 2017-03-29 2:12 GMT+03:00 Denis Magda : > > > >> > > > >>> If we want to make the exception based approach the default one > then > > > the > > > >>> task has to be released in 2.0. > > > >>> > > > >>> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by > > the > > > >>> code freeze data (April 14)? > > > >>> > > > >>> — > > > >>> Denis > > > >>> > > > On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan < > > > dsetrak...@apache.org> > > > >>> wrote: > > > > > > On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin < > > > >>> sergi.vlady...@gmail.com> > > > wrote: > > > > > > > I think updating an Atomic cache from within a transaction > > perfectly > > > >>> makes > > > > sense. For example for some kind of operations logging and so > > forth. > > > >>> Still > > > > I agree that this can be error prone and forbidden by default. I > > > agree > > > >>> with > > > > Yakov that by default we should throw an exception and have some > > kind > > > >>> of > > > > flag (on cache or on TX?) to be able to explicitly enable this > > > >>> behavior. > > > > > > > > > > > > > Agree, this sounds like a good idea. > > > >>> > > > >>> > > > >> > > > > > > > > >
Re: IGNITE-4188, savepoints with atomic cache?
Igniters, Bumping up this discussion. The fix has been implemented and it is fine from the technical point of view, but since the fix did not make it to the Ignite 2.0, the implemented fix [1] now will be a breaking change for current Ignite users. I see the following options: 1) Have the fix merged, but do not change the defaults - atomic caches will still be allowed in transactions by default and only configuration change will make Ignite throw exceptions in this case 2) Have the fix merged as is and describe this change in the release notes 3) Postpone the fix until Ignite 3.0 I would vote for option #1 and change only the defaults in Ignite 3.0. Thoughts? [1] https://issues.apache.org/jira/browse/IGNITE-2313 ср, 5 апр. 2017 г. в 22:53, Дмитрий Рябов : > IGNITE-2313 done, can you review it? > > PR: https://github.com/apache/ignite/pull/1709/files > JIRA: https://issues.apache.org/jira/browse/IGNITE-2313 > CI: http://ci.ignite.apache.org/viewType.html?buildTypeId= > IgniteTests_RatJavadoc_IgniteTests=pull%2F1709% > 2Fhead=buildTypeStatusDiv > > 2017-03-29 20:58 GMT+03:00 Denis Magda : > > > Sorry, I get lost in tickets. > > > > Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes this > > change. > > > > — > > Denis > > > > > On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов > > wrote: > > > > > > Savepoints marked for 2.1, exceptions for 2.0. Do you want me to make > > > exceptions first? > > > > > > 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов : > > > > > >> Finish savepoints or flag for atomic operations? > > >> Not sure about savepoints. Exceptions - yes. https://issues.apache. > > >> org/jira/browse/IGNITE-2313 isn't it? > > >> > > >> 2017-03-29 2:12 GMT+03:00 Denis Magda : > > >> > > >>> If we want to make the exception based approach the default one then > > the > > >>> task has to be released in 2.0. > > >>> > > >>> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by > the > > >>> code freeze data (April 14)? > > >>> > > >>> — > > >>> Denis > > >>> > > On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org> > > >>> wrote: > > > > On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin < > > >>> sergi.vlady...@gmail.com> > > wrote: > > > > > I think updating an Atomic cache from within a transaction > perfectly > > >>> makes > > > sense. For example for some kind of operations logging and so > forth. > > >>> Still > > > I agree that this can be error prone and forbidden by default. I > > agree > > >>> with > > > Yakov that by default we should throw an exception and have some > kind > > >>> of > > > flag (on cache or on TX?) to be able to explicitly enable this > > >>> behavior. > > > > > > > > > Agree, this sounds like a good idea. > > >>> > > >>> > > >> > > > > >
Re: Ignite 2.6 emergency release suggestion
Igniters, Recently we noticed the issue when we don't completely persist some data on the disk: https://issues.apache.org/jira/browse/IGNITE-8780 . In some cases it can lead node to unrecoverable state. I think this problem should be included to release. ср, 13 июн. 2018 г. в 14:06, Alexey Kuznetsov : > Hi! > > Lets also include fix for > https://issues.apache.org/jira/browse/IGNITE-8722 > in this release. > This bug was introduced in IGNITE-7803 (Ignite 2.5) for data structures > that has references to self-type. > > The fix is simple (remove one "else" key word in > IGNITE_BINARY_OBJECT_SERIALIZER) + add test. > I will do this today. > > Please approve. > > > On Wed, Jun 13, 2018 at 2:36 PM, Nikolay Izhikov > wrote: > > > Hello, guys. > > > > I try my best to do review in a next few days. > > > > В Вт, 12/06/2018 в 11:28 -0700, Denis Magda пишет: > > > Agree with Ray. The ticket has been already reviewed and requires us to > > run tests for an isolated module - Spark. > > > > > > Dmitriy Pavlov, Nickolay Izhikov, could you step in as final reviewers > > and merge the changes? > > > > > > -- > > > Denis > > > > > > On Tue, Jun 12, 2018 at 12:01 AM Ray wrote: > > > > Igniters, > > > > > > > > Can you squeeze this ticket into 2.6 scope? > > > > https://issues.apache.org/jira/browse/IGNITE-8534 > > > > > > > > As ignite-spark module is relatively independent module, and there're > > > > already two users in the user list trying to use spark 2.3 with > Ignite > > last > > > > week only. > > > > > > > > http://apache-ignite-users.70518.x6.nabble.com/Spark- > > Ignite-connection-using-Config-file-td21827.html > > > > > > > > http://apache-ignite-users.70518.x6.nabble.com/Spark- > > Ignite-standalone-mode-on-Kubernetes-cluster-td21739.html > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > -- > Alexey Kuznetsov >
[jira] [Created] (IGNITE-8780) File I/O operations must be retried if buffer hasn't read/written completely
Pavel Kovalenko created IGNITE-8780:
---
Summary: File I/O operations must be retried if buffer hasn't
read/written completely
Key: IGNITE-8780
URL: https://issues.apache.org/jira/browse/IGNITE-8780
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Fix For: 2.6
Currently we don't actually ensure that we write or read some buffer completely:
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#writeCheckpointEntry
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#nodeStart
As result we may not write to the disk actual data and after node restart we
can get BufferUnderflowException, like this:
{noformat}
java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Buffer.java:506)
at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:412)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readPointer(GridCacheDatabaseSharedManager.java:1915)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointStatus(GridCacheDatabaseSharedManager.java:1892)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:565)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:525)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:700)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:985)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:671)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:596)
at org.apache.ignite.Ignition.start(Ignition.java:327)
at org.apache.ignite.ci.db.TcHelperDb.start(TcHelperDb.java:67)
at
org.apache.ignite.ci.web.CtxListener.contextInitialized(CtxListener.java:37)
at
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:890)
at
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:532)
at
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:853)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
at
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:452)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:419)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.apache.ignite.ci.web.Launcher.runServer(Launcher.java:68)
at
org.apache.ignite.ci.TcHelperJettyLauncher.main(TcHelperJettyLauncher.java:10)
{noformat}
and node become into unrecoverable state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4183: IGNITE-8781 GridNioServer accepter threads should...
GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/4183 IGNITE-8781 GridNioServer accepter threads should have different names You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-8781 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4183.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4183 commit d9f4078276c6086700c5dd6ee9bc663b8fd5dfbf Author: Andrey Gura Date: 2018-06-13T14:30:18Z IGNITE-8781 GridNioServer accepter threads should have different names ---
Best Effort Affinity for thin clients
Hi, Igniters, Currently, I'm working on the thin C++ client implementation. As you may already know, there is an issue with latency in our thin clients, which also can result in performance issues (you can see the "About Ignite Thin client performance" thread on user list). So, how about we implement some kind of "Best Effort Affinity" for our thin clients? In my opinion, this could be possible and may improve mean latency when using thin clients dramatically. The scenario is following: 1. Thin client connects to one of the node from the provided address list, just as now. 2. When user create instance of CacheClient, thin client requests partition mapping for the cache. 3. Client establishes connections to nodes, which are both in the list, provided by user and in a server node response. 4. When user makes put/get/some other cache operation, thin client makes the best effort to send the request to the node, which stores the data. 5. To update partition mapping, thin client can provide public API, or do it with some timeout. Also, we can add "miss" flag to cache operation response, which whill indicate, that operation was not local for the server node and which thin client can use to understand, that partition mapping has changed to request server node for an update. What do you think? Best Regards, Igor
[GitHub] ignite pull request #4152: IGNITE-8736 Add transaction label to CU.txString(...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4152 ---
[jira] [Created] (IGNITE-8781) nio-acceptor threads are indistinguishable in GridNioServer
Andrey Gura created IGNITE-8781:
---
Summary: nio-acceptor threads are indistinguishable in
GridNioServer
Key: IGNITE-8781
URL: https://issues.apache.org/jira/browse/IGNITE-8781
Project: Ignite
Issue Type: Improvement
Reporter: Andrey Gura
Assignee: Andrey Gura
Fix For: 2.6
nio-acceptor threads are indistinguishable in {{GridNioServer}}. All threads
have exactly same name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4182: GG-13711 : Skipped compatibility submodule while ...
GitHub user ilantukh opened a pull request: https://github.com/apache/ignite/pull/4182 GG-13711 : Skipped compatibility submodule while generating classpath. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-gg-13711 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4182.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4182 commit 4ae01bad9675db9630207d84584b5ec6eeaa987f Author: Ilya Lantukh Date: 2018-06-13T14:04:04Z GG-13711 : Skipped compatibility submodule while generating classpath. ---
Re: IGNITE-640: multimap initial implementation
Amir, Thanks for attempt. As far as I can see you have all changes at this commit: https://github.com/apache/ignite/pull/3926/commits/cd0e50e05d3860788378ebf1a29dc0525460872a You can simply apply it to local branch based on master by patch https://github.com/apache/ignite/commit/cd0e50e05d3860788378ebf1a29dc0525460872a.patch In case you use IDEA, just apply patch from clipboard, and that's will be you PR. BTW, next time you can use easiest way to squash your changes - just to pull all changes from existing PR with squash > git pull https://github.com/apache/ignite.git pull/XXX/head --squash вт, 5 июн. 2018 г. в 19:34, Amir Akhmedov : > Dmitry P., Anton V., > I made some changes and updated the ticket. Also as was asked I tried to > squash the commits into one but looks like I screwed up everything and the > PR now looks completely terrible. Since I'm not an advanced git user, could > you please check the PR and let me know if anything could be done there? If > not I will try to create a new PR. > > Thanks, > Amir > > On Tue, May 29, 2018 at 10:37 AM, Dmitry Pavlov > wrote: > > > Hi Amir, > > > > As far as I know, several Igniters provided some feedback in ticket. Are > > you agree? > > > > Sincerely, > > Dmitriy Pavlov > > > > чт, 10 мая 2018 г. в 20:01, Dmitry Pavlov : > > > > > Hi Amir, > > > > > > This is a very necessary contribution, the patch defenetely will not be > > > ignored. > > > > > > Igniters, > > > > > > Who can make a review from the committers? > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > вт, 8 мая 2018 г. в 5:52, Amir Akhmedov : > > > > > >> Hi Igniters, > > >> > > >> Can someone take a look at this PR please? > > >> > > >> Thanks, > > >> Amir > > >> > > >> On Mon, Apr 30, 2018 at 5:28 AM, Pavel Tupitsyn > > > >> wrote: > > >> > > >> > Hi Amir, > > >> > > > >> > I have filed [1] for multimap in .NET, it will be done later. > > >> > In order to fix IgniteParityTest failures, please add the following > to > > >> > MissingMembers array there: > > >> > > > >> > "multimap" // IGNITE-8425 > > >> > > > >> > Thanks, > > >> > Pavel > > >> > > > >> > > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-8425 > > >> > > > >> > On Sun, Apr 29, 2018 at 11:32 PM, Amir Akhmedov < > > >> amir.akhme...@gmail.com> > > >> > wrote: > > >> > > > >> > > Hi Igniters, > > >> > > > > >> > > I raised a pull request [1] for Ignite multimap [2]. TC run [3] > > seems > > >> ok > > >> > to > > >> > > me, some tests are failed though. Can someone review it please and > > >> let me > > >> > > know? > > >> > > > > >> > > Thanks, > > >> > > Amir > > >> > > > > >> > > [1] https://github.com/apache/ignite/pull/3926 > > >> > > [2] https://issues.apache.org/jira/browse/IGNITE-640 > > >> > > [3] > > >> > > https://ci.ignite.apache.org/viewLog.html?buildId=1255210 > > >> > > b=buildResultsDiv=IgniteTests24Java8_RunAll > > >> > > > > >> > > > >> > > > > > >
[GitHub] ignite pull request #4181: IGNITE-8777: REST: metadata command failed on clu...
GitHub user chandresh-pancholi opened a pull request: https://github.com/apache/ignite/pull/4181 IGNITE-8777: REST: metadata command failed on cluster of size 1 Signed-off-by: Chandresh Pancholi You can merge this pull request into a Git repository by running: $ git pull https://github.com/chandresh-pancholi/ignite master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4181.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4181 commit 682ed08ca9980c8f267c85358bb2ee829b4b3553 Author: Chandresh Pancholi Date: 2018-06-13T12:00:18Z IGNITE-8777: REST: metadata command failed on cluster of size 1 Signed-off-by: Chandresh Pancholi ---
[jira] [Created] (IGNITE-8779) Web console: simplify E2E test runner
Ilya Borisov created IGNITE-8779:
Summary: Web console: simplify E2E test runner
Key: IGNITE-8779
URL: https://issues.apache.org/jira/browse/IGNITE-8779
Project: Ignite
Issue Type: Improvement
Components: wizards
Reporter: Ilya Borisov
Assignee: Alexander Kalinin
The way we run E2E tests now significantly overlaps with a runner provided by
TestCafe CLI. This happens because:
# Ignite TestCafe runner uses environment variables to pass parameters.
# A need to start custom backend environment.
I think we can do better, the optimized result might look like a simple npm
script:
{{ concurrently "npm run env" "testcafe --runner=teamcity" }}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4180: IGNITE-8778 Cache tests fail due short timeout
GitHub user mcherkasov opened a pull request: https://github.com/apache/ignite/pull/4180 IGNITE-8778 Cache tests fail due short timeout You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-master-8778 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4180.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4180 commit 1237a019197653c2e12c8d6bafccaefe6def67ac Author: mcherkasov Date: 2018-06-13T09:27:03Z IGNITE-8778 Cache tests fail due short timeout ---
[GitHub] ignite pull request #4179: IGNITE-8184 ZookeeperDiscoverySpiTest#testTopolog...
GitHub user dgarus opened a pull request: https://github.com/apache/ignite/pull/4179 IGNITE-8184 ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk* tests fail You can merge this pull request into a Git repository by running: $ git pull https://github.com/dgarus/ignite ignite-8184 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4179.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4179 commit 366a664c55ec461b4effe48e15500796277f5042 Author: Garus Denis Date: 2018-06-13T09:04:19Z IGNITE-8184. check TC fail ---
[jira] [Created] (IGNITE-8778) Cache tests fail due short timeout
Mikhail Cherkasov created IGNITE-8778: - Summary: Cache tests fail due short timeout Key: IGNITE-8778 URL: https://issues.apache.org/jira/browse/IGNITE-8778 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Cache tests can fail due time out: [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6515019727174930828=testDetails] usually it passes, tests take ~50seconds, which is close to timeout. If TC is overloaded, tests can take >60sec, which leads to false failures. we need to increase timeout to avoid this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4178: IGNITE-8763 java.nio.file.AccessDeniedException i...
GitHub user alex-plekhanov opened a pull request: https://github.com/apache/ignite/pull/4178 IGNITE-8763 java.nio.file.AccessDeniedException is not handled with default failure handler You can merge this pull request into a Git repository by running: $ git pull https://github.com/alex-plekhanov/ignite ignite-8763 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4178.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4178 commit 18d8fb7148c1197402e0e89e9b7797a1ee38b492 Author: Aleksey Plekhanov Date: 2018-06-09T15:05:28Z IGNITE-8763 Reproducer commit c55c74425e9af807d2c521778e1185fc1e726520 Author: Aleksey Plekhanov Date: 2018-06-09T15:41:54Z IGNITE-8763 Fix commit 3cf690ffe5e59ae8e9bb54b7266e33a35e7ada89 Author: Aleksey Plekhanov Date: 2018-06-09T16:16:56Z IGNITE-8763 Fix 2 ---
Re: Ignite 2.6 emergency release suggestion
Hello, guys. I try my best to do review in a next few days. В Вт, 12/06/2018 в 11:28 -0700, Denis Magda пишет: > Agree with Ray. The ticket has been already reviewed and requires us to run > tests for an isolated module - Spark. > > Dmitriy Pavlov, Nickolay Izhikov, could you step in as final reviewers and > merge the changes? > > -- > Denis > > On Tue, Jun 12, 2018 at 12:01 AM Ray wrote: > > Igniters, > > > > Can you squeeze this ticket into 2.6 scope? > > https://issues.apache.org/jira/browse/IGNITE-8534 > > > > As ignite-spark module is relatively independent module, and there're > > already two users in the user list trying to use spark 2.3 with Ignite last > > week only. > > > > http://apache-ignite-users.70518.x6.nabble.com/Spark-Ignite-connection-using-Config-file-td21827.html > > > > http://apache-ignite-users.70518.x6.nabble.com/Spark-Ignite-standalone-mode-on-Kubernetes-cluster-td21739.html > > > > > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ signature.asc Description: This is a digitally signed message part
[GitHub] ignite pull request #2705: IGNITE-584: proper datastructures setDataMap fill...
Github user zstan closed the pull request at: https://github.com/apache/ignite/pull/2705 ---
