[jira] [Commented] (IGNITE-5838) The IgniteCache.loadCacheAsync method is not executed asynchronously.
[ https://issues.apache.org/jira/browse/IGNITE-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115301#comment-16115301 ] Yujue Li commented on IGNITE-5838: -- If this method is already known that cannot be executed asynchronously, then this method should not seem to be provided. > The IgniteCache.loadCacheAsync method is not executed asynchronously. > - > > Key: IGNITE-5838 > URL: https://issues.apache.org/jira/browse/IGNITE-5838 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.0 >Reporter: Yujue Li > Fix For: 2.2 > > > The IgniteCache.loadCacheAsync method is not executed asynchronously. > for example,in the > https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/datagrid/store/spring/CacheSpringStoreExample.java: > line 129: > If modified to: > cache.loadCacheAsync(null, ENTRY_COUNT); > We will find that the cache is not loaded asynchronously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4800) Lucene query may fails with NPE.
[ https://issues.apache.org/jira/browse/IGNITE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114878#comment-16114878 ] Dmitriy Pavlov commented on IGNITE-4800: Could you please check failures on TC in master http://ci.ignite.apache.org/viewLog.html?buildId=757487&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgnitePlatformNet and same in PR http://ci.ignite.apache.org/viewLog.html?buildId=748756&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgnitePlatformNet > Lucene query may fails with NPE. > > > Key: IGNITE-4800 > URL: https://issues.apache.org/jira/browse/IGNITE-4800 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Fix For: 2.2 > > Attachments: application_lucene.log > > > GridLuceneFile 'buffers' field is set to null regardless file can be used in > GridLuceneInputStream by some query. > We should add a guard, that will prevent 'buffers' to be cleared until all > GridLuceneInputStream-s is closed. > Userlist discussion: > http://apache-ignite-users.70518.x6.nabble.com/Lucene-like-Contains-phrase-query-td10808.html#a10956 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5851) Automatically activate cluster if baseline topology is reached
[ https://issues.apache.org/jira/browse/IGNITE-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114872#comment-16114872 ] Dmitriy Pavlov commented on IGNITE-5851: See also design proposal https://cwiki.apache.org/confluence/display/IGNITE/Automatic+activation+design+-+draft and discussion http://apache-ignite-developers.2346864.n4.nabble.com/Cluster-auto-activation-design-proposal-td20295.html > Automatically activate cluster if baseline topology is reached > -- > > Key: IGNITE-5851 > URL: https://issues.apache.org/jira/browse/IGNITE-5851 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk > Fix For: 2.2 > > > When we have an API for baseline topology management, we can automatically > activate the cluster once all the nodes from the baseline topology are > started. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4181) The several runs of ServicesExample causes NPE
[
https://issues.apache.org/jira/browse/IGNITE-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-4181:
Fix Version/s: (was: 2.2)
2.1
> The several runs of ServicesExample causes NPE
> --
>
> Key: IGNITE-4181
> URL: https://issues.apache.org/jira/browse/IGNITE-4181
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6, 1.7, 2.0
> Environment: Windows 10, Oracle JDK 7
>Reporter: Sergey Kozlov
>Assignee: Dmitriy Sorokin
> Labels: newbie
> Fix For: 2.1
>
>
> 0. Open example project in IDEA
> 1. Start 2-3 {{ExampleNodeStartup}}
> 2. Run {{ServicesExample}} several times.
> Sometimes it causes NullPointerException:
> {noformat}
> Executing closure [mapSize=10]
> Service was cancelled: myNodeSingletonService
> [15:37:20,020][INFO ][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled
> service instance [name=myNodeSingletonService,
> execId=88a92a4d-c1cb-4a9b-8930-c67ac7f42bf3]
> [15:37:20,032][INFO ][sys-#33%null%][GridCacheProcessor] Stopped cache:
> myNodeSingletonService
> [15:37:20,033][INFO
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10,
> minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT,
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,045][INFO ][sys-#39%null%][GridCacheProcessor] Stopped cache:
> myClusterSingletonService
> [15:37:20,046][INFO
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10,
> minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT,
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,062][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager]
> Node left topology: TcpDiscoveryNode
> [id=4f9cbc67-d756-4c25-9ee4-aee6528da024, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1,
> 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269],
> sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0,
> /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10,
> intOrder=7, lastExchangeTime=1478522239236, loc=false,
> ver=1.7.3#20161107-sha1:5132ac87, isClient=true]
> [15:37:20,063][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager]
> Topology snapshot [ver=11, servers=3, clients=0, CPUs=8, heap=11.0GB]
> [15:37:20,064][INFO ][sys-#44%null%][GridCacheProcessor] Stopped cache:
> myMultiService
> [15:37:20,066][INFO
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10,
> minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT,
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,076][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started
> cache [name=myClusterSingletonService, mode=PARTITIONED]
> [15:37:20,115][INFO
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10,
> minorTopVer=7], evt=DISCOVERY_CUSTOM_EVT,
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,121][INFO
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=11,
> minorTopVer=0], evt=NODE_LEFT, node=4f9cbc67-d756-4c25-9ee4-aee6528da024]
> [15:37:20,133][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started
> cache [name=myMultiService, mode=PARTITIONED]
> [15:37:20,135][ERROR][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11,
> minorTopVer=1], nodeId=5faac72a, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> [15:37:2
[jira] [Commented] (IGNITE-5926) Puts on near cache hangs
[ https://issues.apache.org/jira/browse/IGNITE-5926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114848#comment-16114848 ] vinay commented on IGNITE-5926: --- This is just a thought that near caches will mostly have very frequent evictions considering their small size (as compared to server cache) and considering cases where client is performing a lot of reads or writes. This may significantly increase communications between client and server. I don't have much knowledge on internal working / implementation of ignite but there may be more complexities in this approach when we consider cases like node failures. I think there may be some better approach to solve this problem than sending communication from client on each eviction and making server aware of each eviction on near caches. > Puts on near cache hangs > > > Key: IGNITE-5926 > URL: https://issues.apache.org/jira/browse/IGNITE-5926 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.0, 2.1 >Reporter: vinay > Fix For: 2.2 > > Attachments: IgniteNearCacheProblem.java > > > Cache puts on near cache on client node hangs after putting same number of > keys (if keys and values are same during test). Most probably problem occurs > when cache on server reaches max memory and starts page eviction. *Attaching > java class with main method to reproduce problem*. If near cache is not used > then the same test works fine. > Steps to reproduce > # Start a server node with one memory region with max size 100 MB. Page > Evction Strategy as RANDOM_LRU. Set this memory region as default. Create a > REPLICATED cache as part of server's IgniteConfiguration. > # Start a client node and create a near cache for the cache created on > server. Keep near cache init size and max size 1000 with eviction policy LRU. > # Start a infinite while loop to put objects in near cache. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5947) ClassCastException when two-dimensional array is fetched from cache
Valentin Kulichenko created IGNITE-5947:
---
Summary: ClassCastException when two-dimensional array is fetched
from cache
Key: IGNITE-5947
URL: https://issues.apache.org/jira/browse/IGNITE-5947
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.1
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 2.2
When an instance of {{Object[][]}} is put into cache, and then read from there,
the following exception is thrown:
{noformat}
Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object;
cannot be cast to [[Ljava.lang.Object;
{noformat}
Reproducer attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5947) ClassCastException when two-dimensional array is fetched from cache
[
https://issues.apache.org/jira/browse/IGNITE-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-5947:
Attachment: TestMain.java
> ClassCastException when two-dimensional array is fetched from cache
> ---
>
> Key: IGNITE-5947
> URL: https://issues.apache.org/jira/browse/IGNITE-5947
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 2.2
>
> Attachments: TestMain.java
>
>
> When an instance of {{Object[][]}} is put into cache, and then read from
> there, the following exception is thrown:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object;
> cannot be cast to [[Ljava.lang.Object;
> {noformat}
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5946) Ignite WebSessions: Flaky failure for WebSessionSelfTest.testClientReconnectRequest() and subclasses
[
https://issues.apache.org/jira/browse/IGNITE-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5946:
---
Description:
Success rate on Teamcity is ~63%
org.apache.ignite.internal.websession.WebSessionSelfTest#testClientReconnectRequest()
http://ci.ignite.apache.org/viewLog.html?buildId=756773&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteWebSessions#testNameId4440256403233545493
{noformat}
java.lang.AssertionError: Error occurred on grid stop (see log for more
details).
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1961)
{noformat}
{noformat}
[2017-08-04
17:29:33,271][ERROR][test-runner-#1%websession.WebSessionSelfTest%][root]
Failed to stop grid [igniteInstanceName=null, cancel=true]
class org.apache.ignite.IgniteClientDisconnectedException: Client node
disconnected: client
at
org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
at
org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
at
org.apache.ignite.internal.websession.WebSessionSelfTest.testClientReconnectRequest(WebSessionSelfTest.java:163)
at
org.apache.ignite.internal.websession.WebSessionSelfTest.testClientReconnectRequest(WebSessionSelfTest.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Reproducible locally for ~ 1/12 runs (windows 10)
was:
Success rate on Teamcity is ~63%
org.apache.ignite.internal.websession.WebSessionSelfTest#testClientReconnectRequest()
http://ci.ignite.apache.org/viewLog.html?buildId=756773&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteWebSessions#testNameId4440256403233545493
{noformat}
java.lang.AssertionError: Error occurred on grid stop (see log for more
details).
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1961)
{noformat}
{noformat}
[2017-08-04
17:29:33,271][ERROR][test-runner-#1%websession.WebSessionSelfTest%][root]
Failed to stop grid [igniteInstanceName=null, cancel=true]
class org.apache.ignite.IgniteClientDisconnectedException: Client node
disconnected: client
at
org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
at
org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
at
org.apache.ignite.internal.websession.WebSessionSelfTest.testClientReconnectRequest(WebSessionSelfTest.java:163)
at
org.apache.ignite.internal.websession.WebSessionSelfTest.testClientReconnectRequest(WebSessionSelfTest.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noform
[jira] [Updated] (IGNITE-3663) Failed test: Sporadic failures to WebSessionSelfTest.testSessionRenewalDuringLogin()
[
https://issues.apache.org/jira/browse/IGNITE-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-3663:
---
Labels: Muted_test (was: )
> Failed test: Sporadic failures to
> WebSessionSelfTest.testSessionRenewalDuringLogin()
>
>
> Key: IGNITE-3663
> URL: https://issues.apache.org/jira/browse/IGNITE-3663
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Labels: Muted_test
>
> Stack trace:
> {code}
> java.io.FileNotFoundException: \tmp\realm.properties (The system cannot find
> the path specified)
> at java.io.FileOutputStream.open(Native Method)
> at java.io.FileOutputStream.(FileOutputStream.java:221)
> at java.io.FileOutputStream.(FileOutputStream.java:171)
> at java.io.FileWriter.(FileWriter.java:90)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.createRealm(WebSessionSelfTest.java:895)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.startServerWithLoginService(WebSessionSelfTest.java:856)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.testSessionRenewalDuringLogin(WebSessionSelfTest.java:308)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.testSessionRenewalDuringLogin(WebSessionSelfTest.java:92)
> --- Stdout: ---
> [09:22:21,509][INFO ][main][root] >>> Starting test:
> WebSessionSelfTest#testSessionRenewalDuringLogin <<<
> [09:22:21,524][INFO ][main][root] >>> Stopping test:
> WebSessionSelfTest#testSessionRenewalDuringLogin in 15 ms <<<
> [09:22:21,524][INFO ][main][root] >>> Stopping test class: WebSessionSelfTest
> <<<
> --- Stderr: ---
> [09:22:21,522][ERROR][main][root] Test failed.
> java.io.FileNotFoundException: \tmp\realm.properties (The system cannot find
> the path specified)
> at java.io.FileOutputStream.open(Native Method)
> at java.io.FileOutputStream.(FileOutputStream.java:221)
> at java.io.FileOutputStream.(FileOutputStream.java:171)
> at java.io.FileWriter.(FileWriter.java:90)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.createRealm(WebSessionSelfTest.java:895)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.startServerWithLoginService(WebSessionSelfTest.java:856)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.testSessionRenewalDuringLogin(WebSessionSelfTest.java:308)
> at
> org.apache.ignite.internal.websession.WebSessionSelfTest.testSessionRenewalDuringLogin(WebSessionSelfTest.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5946) Ignite WebSessions: Flaky failure for WebSessionSelfTest.testClientReconnectRequest() and subclasses
Dmitriy Pavlov created IGNITE-5946:
--
Summary: Ignite WebSessions: Flaky failure for
WebSessionSelfTest.testClientReconnectRequest() and subclasses
Key: IGNITE-5946
URL: https://issues.apache.org/jira/browse/IGNITE-5946
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1
Reporter: Dmitriy Pavlov
Fix For: 2.2
Success rate on Teamcity is ~63%
org.apache.ignite.internal.websession.WebSessionSelfTest#testClientReconnectRequest()
http://ci.ignite.apache.org/viewLog.html?buildId=756773&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteWebSessions#testNameId4440256403233545493
{noformat}
java.lang.AssertionError: Error occurred on grid stop (see log for more
details).
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1961)
{noformat}
{noformat}
[2017-08-04
17:29:33,271][ERROR][test-runner-#1%websession.WebSessionSelfTest%][root]
Failed to stop grid [igniteInstanceName=null, cancel=true]
class org.apache.ignite.IgniteClientDisconnectedException: Client node
disconnected: client
at
org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
at
org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
at
org.apache.ignite.internal.websession.WebSessionSelfTest.testClientReconnectRequest(WebSessionSelfTest.java:163)
at
org.apache.ignite.internal.websession.WebSessionSelfTest.testClientReconnectRequest(WebSessionSelfTest.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5549:
---
Attachment: ThreadDump0.log
> Ignite Cache Failover2: test suite hands up from
> CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
> ---
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
> Attachments: ThreadDump0.log
>
>
> Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
> http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
> {noformat}
> ransaction has been already completed.
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:745)
> [16:29:30]W: [org.apache.ignite:ignite-core]
> java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
> [nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
> [topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
> id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
> reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
> otherVer=GridCacheVersion [topVer=11427, order=1501856691702,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null,
> key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
> [idHash=742616132, hash=-1080846605, key=48],
> masks=local=1|owner=0|ready=0|reentry=0|used=0|tx=1|single_
[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5549:
---
Priority: Critical (was: Major)
> Ignite Cache Failover2: test suite hands up from
> CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
> ---
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
>
> Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
> http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
> {noformat}
> ransaction has been already completed.
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:745)
> [16:29:30]W: [org.apache.ignite:ignite-core]
> java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
> [nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
> [topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
> id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
> reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
> otherVer=GridCacheVersion [topVer=11427, order=1501856691702,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null,
> key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
> [idHash=742616132, hash=-1080846605, key=48],
> masks=local=1|owner=0|ready=0|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|
[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5549:
---
Affects Version/s: 2.1
> Ignite Cache Failover2: test suite hands up from
> CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
> ---
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
>
> Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
> http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
> {noformat}
> ransaction has been already completed.
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:745)
> [16:29:30]W: [org.apache.ignite:ignite-core]
> java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
> [nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
> [topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
> id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
> reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
> otherVer=GridCacheVersion [topVer=11427, order=1501856691702,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null,
> key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
> [idHash=742616132, hash=-1080846605, key=48],
> masks=local=1|owner=0|ready=0|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer
[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up for more than 2 hours
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5549:
---
Description:
Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
{noformat}
ransaction has been already completed.
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
[16:29:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
[16:29:30]W: [org.apache.ignite:ignite-core]at
java.lang.Thread.run(Thread.java:745)
[16:29:30]W: [org.apache.ignite:ignite-core]
java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
[nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
[topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
otherVer=GridCacheVersion [topVer=11427, order=1501856691702, nodeOrder=1],
mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null,
key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
[idHash=742616132, hash=-1080846605, key=48],
masks=local=1|owner=0|ready=0|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
prevVer=null, nextVer=null], prev=GridCacheMvccCandidate
[nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
[topVer=11425, order=1501856674174, nodeOrder=1], threadId=216954,
id=30502305, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
otherVer=GridCacheVersion [topVer=11425, order=1501856674174, nodeOrder=1],
mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null,
key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
[idHash=950720167, hash=-15669725
[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() t
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5549:
---
Summary: Ignite Cache Failover2: test suite hands up from
CacheAsyncOperationsFailoverTxTest.testAsyncFailover() t (was: Ignite Cache
Failover2: test suite hands up for more than 2 hours)
> Ignite Cache Failover2: test suite hands up from
> CacheAsyncOperationsFailoverTxTest.testAsyncFailover() t
> -
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
>
> Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
> http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
> {noformat}
> ransaction has been already completed.
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:745)
> [16:29:30]W: [org.apache.ignite:ignite-core]
> java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
> [nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
> [topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
> id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
> reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
> otherVer=GridCacheVersion [topVer=11427, order=1501856691702,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null,
> key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
> [idHash=742616
[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5549:
---
Fix Version/s: 2.2
> Ignite Cache Failover2: test suite hands up from
> CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
> ---
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
>
> Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
> http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
> {noformat}
> ransaction has been already completed.
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:745)
> [16:29:30]W: [org.apache.ignite:ignite-core]
> java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
> [nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
> [topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
> id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
> reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
> otherVer=GridCacheVersion [topVer=11427, order=1501856691702,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null,
> key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbstractTest$TestKey
> [idHash=742616132, hash=-1080846605, key=48],
> masks=local=1|owner=0|ready=0|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=nul
[jira] [Updated] (IGNITE-5549) Ignite Cache Failover2: test suite hands up from CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
[
https://issues.apache.org/jira/browse/IGNITE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5549:
---
Summary: Ignite Cache Failover2: test suite hands up from
CacheAsyncOperationsFailoverTxTest.testAsyncFailover() (was: Ignite Cache
Failover2: test suite hands up from
CacheAsyncOperationsFailoverTxTest.testAsyncFailover() t)
> Ignite Cache Failover2: test suite hands up from
> CacheAsyncOperationsFailoverTxTest.testAsyncFailover()
> ---
>
> Key: IGNITE-5549
> URL: https://issues.apache.org/jira/browse/IGNITE-5549
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.2
>
>
> Timeout came from CacheAsyncOperationsFailoverTxTest.testAsyncFailover() test:
> http://ci.ignite.apache.org/viewLog.html?buildId=756819&buildTypeId=Ignite20Tests_IgniteCacheFailover2&tab=buildResultsDiv
> {noformat}
> ransaction has been already completed.
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:787)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:727)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:683)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:95)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:165)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:163)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:485)
> [16:29:30]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:745)
> [16:29:30]W: [org.apache.ignite:ignite-core]
> java.lang.AssertionError: Invalid threadId [this=GridCacheMvccCandidate
> [nodeId=d6f0c17e-68b3-4da7-bd02-914ada70, ver=GridCacheVersion
> [topVer=11427, order=1501856691702, nodeOrder=1], threadId=211336,
> id=30502322, topVer=AffinityTopologyVersion [topVer=126, minorTopVer=0],
> reentry=null, otherNodeId=d6f0c17e-68b3-4da7-bd02-914ada70,
> otherVer=GridCacheVersion [topVer=11427, order=1501856691702,
> nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null,
> key=org.apache.ignite.internal.processors.cache.distributed.CacheAsyncOperationsFailoverAbs
[jira] [Updated] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
[
https://issues.apache.org/jira/browse/IGNITE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5945:
---
Labels: MakeTeamcityGreenAgain (was: )
> Flaky failure in IgniteCache 5:
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
> --
>
> Key: IGNITE-5945
> URL: https://issues.apache.org/jira/browse/IGNITE-5945
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Fail is reproducable locally 2 times per 20 runs
> On TeamCity test success rate is 88,2%
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
Dmitriy Pavlov created IGNITE-5945:
--
Summary: Flaky failure in IgniteCache 5:
IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
Key: IGNITE-5945
URL: https://issues.apache.org/jira/browse/IGNITE-5945
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1
Reporter: Dmitriy Pavlov
Fix For: 2.2
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
{noformat}
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Fail is reproducable locally 2 times per 20 runs
On TeamCity test success rate is 88,2%
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-4931) Safe way for deactivate cluster
[ https://issues.apache.org/jira/browse/IGNITE-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114579#comment-16114579 ] Dmitriy Pavlov commented on IGNITE-4931: Following tests were muted with link to this issue: ClusterStatePartitionedSelfTest.testDeactivationWithPendingLock ClusterStatePartitionedSelfTest.testDeactivationWithPendingTransaction ClusterStateReplicatedSelfTest.testDeactivationWithPendingLock ClusterStateReplicatedSelfTest.testDeactivationWithPendingTransaction > Safe way for deactivate cluster > --- > > Key: IGNITE-4931 > URL: https://issues.apache.org/jira/browse/IGNITE-4931 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Dmitriy Govorukhin > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.2 > > > We must provide safe way for deactivate cluster, i mean we must wait while > all cache operation, transaction and etc. comleted before start deactivation > process, in current implementation we do not wait while transaction comlete, > (forcibly stop cache during transaction). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4931) Safe way for deactivate cluster
[ https://issues.apache.org/jira/browse/IGNITE-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-4931: --- Labels: MakeTeamcityGreenAgain Muted_test (was: ) > Safe way for deactivate cluster > --- > > Key: IGNITE-4931 > URL: https://issues.apache.org/jira/browse/IGNITE-4931 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Dmitriy Govorukhin > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.2 > > > We must provide safe way for deactivate cluster, i mean we must wait while > all cache operation, transaction and etc. comleted before start deactivation > process, in current implementation we do not wait while transaction comlete, > (forcibly stop cache during transaction). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5841) Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with assertions
[
https://issues.apache.org/jira/browse/IGNITE-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5841:
---
Affects Version/s: 2.1
> Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with
> assertions
> --
>
> Key: IGNITE-5841
> URL: https://issues.apache.org/jira/browse/IGNITE-5841
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Found during PR testing, but fails also for master
> http://ci.ignite.apache.org/viewLog.html?buildId=740511&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteSpi
> There is flaky test failing in different suites
> TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFailTopologyChanged
> Success rate 82,1%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
> TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged
> Success rate 84,3%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5841) Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with assertions
[
https://issues.apache.org/jira/browse/IGNITE-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-5841:
---
Fix Version/s: 2.2
> Ignite SPI Suite: testReconnectAfterFailTopologyChanged() test failure with
> assertions
> --
>
> Key: IGNITE-5841
> URL: https://issues.apache.org/jira/browse/IGNITE-5841
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Found during PR testing, but fails also for master
> http://ci.ignite.apache.org/viewLog.html?buildId=740511&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteSpi
> There is flaky test failing in different suites
> TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFailTopologyChanged
> Success rate 82,1%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
> TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged
> Success rate 84,3%
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.reconnectAfterFail(TcpClientDiscoverySpiSelfTest.java:1422)
> at
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testReconnectAfterFailTopologyChanged(TcpClientDiscoverySpiSelfTest.java:1331)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5944) Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system
[ https://issues.apache.org/jira/browse/IGNITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-5944: -- Attachment: pradeep-config.xml IGFSExample.java > Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system > > > Key: IGNITE-5944 > URL: https://issues.apache.org/jira/browse/IGNITE-5944 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Mikhail Cherkasov > Attachments: IGFSExample.java, pradeep-config.xml > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5944) Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system
[ https://issues.apache.org/jira/browse/IGNITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-5944: -- Description: (was: I can't run example) > Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system > > > Key: IGNITE-5944 > URL: https://issues.apache.org/jira/browse/IGNITE-5944 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Mikhail Cherkasov > Attachments: IGFSExample.java, pradeep-config.xml > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-5944) Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system
[ https://issues.apache.org/jira/browse/IGNITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov resolved IGNITE-5944. --- Resolution: Cannot Reproduce it works fine with 2.0.0 > Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system > > > Key: IGNITE-5944 > URL: https://issues.apache.org/jira/browse/IGNITE-5944 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Mikhail Cherkasov > Attachments: IGFSExample.java, pradeep-config.xml > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5944) Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system
[ https://issues.apache.org/jira/browse/IGNITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-5944: -- Description: I can't run example > Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system > > > Key: IGNITE-5944 > URL: https://issues.apache.org/jira/browse/IGNITE-5944 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Mikhail Cherkasov > Attachments: IGFSExample.java, pradeep-config.xml > > > I can't run example -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5944) Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system
Mikhail Cherkasov created IGNITE-5944: - Summary: Ignite 1.9 can't be started with configured IGFS and Hadoop secondary system Key: IGNITE-5944 URL: https://issues.apache.org/jira/browse/IGNITE-5944 Project: Ignite Issue Type: Bug Affects Versions: 1.9 Reporter: Mikhail Cherkasov -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5384) JDBC Driver: implement ResultSet#getDate(int, Calendar)
[
https://issues.apache.org/jira/browse/IGNITE-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114538#comment-16114538
]
Taras Ledkov edited comment on IGNITE-5384 at 8/4/17 3:47 PM:
--
Looks like we must not implement date conversion explicitly because Ignite
store a date as {{long millis}} gathered from {{Date}}.
JDBC javadoc says (for all methods of the {{ResultSet}} that contain Calendar
argument):
{quote}
This method uses the given calendar to construct an appropriate millisecond
value for the date if the underlying database does not store
timezone information.
{quote}
So, Ignite store timezone information because the UTC milliseconds are stored.
[~vozerov], please provide your thoughts.
was (Author: tledkov-gridgain):
Looks like we must not implement date conversion explicitly because Ignite
store a date as {{long millis}} gathered from {{Date}}.
For all methods of the {{ResultSet}} that contain Calendar to convert JDBC
javadoc says:
{quote}
This method uses the given calendar to construct an appropriate millisecond
value for the date if the underlying database does not store
timezone information.
{quote}
So, Ignite store timezone information because the UTC milliseconds are stored.
[~vozerov], please provide your thoughts.
> JDBC Driver: implement ResultSet#getDate(int, Calendar)
> ---
>
> Key: IGNITE-5384
> URL: https://issues.apache.org/jira/browse/IGNITE-5384
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> Current implementation doesn't use Calendar object to convert the date.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5384) JDBC Driver: implement ResultSet#getDate(int, Calendar)
[
https://issues.apache.org/jira/browse/IGNITE-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114538#comment-16114538
]
Taras Ledkov commented on IGNITE-5384:
--
Looks like we must not implement date conversion explicitly because Ignite
store a date as {{long millis}} gathered from {{Date}}.
For all methods of the {{ResultSet}} that contain Calendar to convert JDBC
javadoc says:
{quote}
This method uses the given calendar to construct an appropriate millisecond
value for the date if the underlying database does not store
timezone information.
{quote}
So, Ignite store timezone information because the UTC milliseconds are stored.
[~vozerov], please provide your thoughts.
> JDBC Driver: implement ResultSet#getDate(int, Calendar)
> ---
>
> Key: IGNITE-5384
> URL: https://issues.apache.org/jira/browse/IGNITE-5384
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> Current implementation doesn't use Calendar object to convert the date.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5842) ODBC: Make sure ODBC driver works correctly with RazorSQL.
[
https://issues.apache.org/jira/browse/IGNITE-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114531#comment-16114531
]
Igor Sapego commented on IGNITE-5842:
-
Found and fixed one more issue - IGNITE-5939
> ODBC: Make sure ODBC driver works correctly with RazorSQL.
> --
>
> Key: IGNITE-5842
> URL: https://issues.apache.org/jira/browse/IGNITE-5842
> Project: Ignite
> Issue Type: Improvement
> Components: odbc
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: odbc
> Fix For: 2.2
>
>
> Users often try to use ODBC driver to connect to Ignite with RazorSQL.
> However, it can't be used with our driver, as it tries to configure driver to
> act according to unsupported ODBC version. Here is the log:
> {noformat}
> razorsql12d8-1374 ENTER SQLAllocEnv
> HENV * 0x2FBEECB0
> razorsql12d8-1374 EXIT SQLAllocEnv with return code 0
> (SQL_SUCCESS)
> HENV * 0x2FBEECB0 ( 0x003DE650)
> razorsql12d8-1374 ENTER SQLAllocConnect
> HENV0x003DE650
> HDBC * 0x2FBEEC10
> razorsql12d8-1374 EXIT SQLAllocConnect with return code 0
> (SQL_SUCCESS)
> HENV0x003DE650
> HDBC * 0x2FBEEC10 ( 0x003DE6D0)
> razorsql12d8-1374 ENTER SQLSetConnectOption
> HDBC0x003DE6D0
> SQLINTEGER 103
> SQLPOINTER35
> razorsql12d8-1374 EXIT SQLSetConnectOption with return code 0
> (SQL_SUCCESS)
> HDBC0x003DE6D0
> SQLINTEGER 103
> SQLPOINTER35
> razorsql12d8-1374 ENTER SQLDriverConnectW
> HDBC0x003DE6D0
> HWND0x
> WCHAR * 0x6F861F7C [ -3] "**\ 0"
> SWORD -3
> WCHAR * 0x6F861F7C
> SWORD -3
> SWORD * 0x
> UWORD0
> razorsql12d8-1374 EXIT SQLDriverConnectW with return code -1
> (SQL_ERROR)
> HDBC0x003DE6D0
> HWND0x
> WCHAR * 0x6F861F7C [ -3] "**\ 0"
> SWORD -3
> WCHAR * 0x6F861F7C
> SWORD -3
> SWORD * 0x
> UWORD0
> DIAG [S1000] ODBC version is not supported. (0)
> DIAG [08001] Failed to establish connection with the host. (0)
> razorsql12d8-1374 ENTER SQLErrorW
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4
> SDWORD *0x2FBEEB3C
> WCHAR * 0x2FBEE6F4
> SWORD 300
> SWORD * 0x2FBEEB38
> razorsql12d8-1374 EXIT SQLErrorW with return code 0
> (SQL_SUCCESS)
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4 [ 5] "S1000"
> SDWORD *0x2FBEEB3C (0)
> WCHAR * 0x2FBEE6F4 [ 30] "ODBC version is not
> supported."
> SWORD 300
> SWORD * 0x2FBEEB38 (30)
> razorsql12d8-1374 ENTER SQLErrorW
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4
> SDWORD *0x2FBEEB3C
> WCHAR * 0x2FBEE6F4
> SWORD 300
> SWORD * 0x2FBEEB38
> razorsql12d8-1374 EXIT SQLErrorW with return code 0
> (SQL_SUCCESS)
> HENV0x
> HDBC0x003DE6D0
> HSTMT 0x
> WCHAR * 0x2FBEEAF4 [ 5] "08001"
> SDWORD *0x2FBEEB3C (0)
> WCHAR * 0x2FBEE6F4 [ 45] "Failed to establish
> connection with the host."
> SW
[jira] [Commented] (IGNITE-5939) ODBC: SQLColAttributes should work with legacy attribute codes.
[
https://issues.apache.org/jira/browse/IGNITE-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114528#comment-16114528
]
ASF GitHub Bot commented on IGNITE-5939:
Github user isapego closed the pull request at:
https://github.com/apache/ignite/pull/2399
> ODBC: SQLColAttributes should work with legacy attribute codes.
> ---
>
> Key: IGNITE-5939
> URL: https://issues.apache.org/jira/browse/IGNITE-5939
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> According to
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function
>
> {quote}
> The #define values of the ODBC 2.x {{FieldIdentifiers}}
> {{SQL_COLUMN_LENGTH}}, {{SQL_COLUMN_PRECISION}}, and {{SQL_COLUMN_SCALE}} are
> different from the #define values of the ODBC 3.x {{FieldIdentifiers}}
> {{SQL_DESC_PRECISION}}, {{SQL_DESC_SCALE}}, and {{SQL_DESC_LENGTH}}. An ODBC
> 2.x driver need only support the ODBC 2.x values. An ODBC 3.x driver must
> support both "{{SQL_COLUMN}}" and "{{SQL_DESC}}" values for these three
> {{FieldIdentifiers}}. These values are different because precision, scale,
> and length are defined differently in ODBC 3.x than they were in ODBC 2.x.
> {quote}
> Currently, {{SQLColAttributes}} does not work with these three identifiers in
> our driver. Need to be fixed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5941) Index with long name stores incorrect
[
https://issues.apache.org/jira/browse/IGNITE-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-5941:
--
Attachment: LongIndexNameTest.java
> Index with long name stores incorrect
> -
>
> Key: IGNITE-5941
> URL: https://issues.apache.org/jira/browse/IGNITE-5941
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
> Attachments: LongIndexNameTest.java
>
>
> SQL query by Index with long name return inconsistent result after cluster
> restart and recover from storage. At the same time a query by other index
> (with more shorter name) works correctly before and after recovery.
> For example long index name:
> {code}
> QueryIndex index = new QueryIndex("name", true,
> "COM.SBT.AZIMUTH_PSI.PUBLISHER.ENTITIES.PUB.PARTICLES.CARPORT#MODELCOM.SBT.AZIMUTH_PSI.PUBLISHER.ENTITIES.PUB.PARTICLES.CARPORT");
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-4800) Lucene query may fails with NPE.
[ https://issues.apache.org/jira/browse/IGNITE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114484#comment-16114484 ] ASF GitHub Bot commented on IGNITE-4800: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2315 > Lucene query may fails with NPE. > > > Key: IGNITE-4800 > URL: https://issues.apache.org/jira/browse/IGNITE-4800 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Fix For: 2.2 > > Attachments: application_lucene.log > > > GridLuceneFile 'buffers' field is set to null regardless file can be used in > GridLuceneInputStream by some query. > We should add a guard, that will prevent 'buffers' to be cleared until all > GridLuceneInputStream-s is closed. > Userlist discussion: > http://apache-ignite-users.70518.x6.nabble.com/Lucene-like-Contains-phrase-query-td10808.html#a10956 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5939) ODBC: SQLColAttributes should work with legacy attribute codes.
[
https://issues.apache.org/jira/browse/IGNITE-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114482#comment-16114482
]
Pavel Tupitsyn commented on IGNITE-5939:
[~isapego] looks good to me.
> ODBC: SQLColAttributes should work with legacy attribute codes.
> ---
>
> Key: IGNITE-5939
> URL: https://issues.apache.org/jira/browse/IGNITE-5939
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> According to
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function
>
> {quote}
> The #define values of the ODBC 2.x {{FieldIdentifiers}}
> {{SQL_COLUMN_LENGTH}}, {{SQL_COLUMN_PRECISION}}, and {{SQL_COLUMN_SCALE}} are
> different from the #define values of the ODBC 3.x {{FieldIdentifiers}}
> {{SQL_DESC_PRECISION}}, {{SQL_DESC_SCALE}}, and {{SQL_DESC_LENGTH}}. An ODBC
> 2.x driver need only support the ODBC 2.x values. An ODBC 3.x driver must
> support both "{{SQL_COLUMN}}" and "{{SQL_DESC}}" values for these three
> {{FieldIdentifiers}}. These values are different because precision, scale,
> and length are defined differently in ODBC 3.x than they were in ODBC 2.x.
> {quote}
> Currently, {{SQLColAttributes}} does not work with these three identifiers in
> our driver. Need to be fixed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used
[ https://issues.apache.org/jira/browse/IGNITE-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin resolved IGNITE-5795. -- Resolution: Workaround I discussed this with [~vozerov] and confirmed we do not want to fix this since any fix would violate Ignite design ideology. To work around the problem in addition to specifying affinity key field using @AffinityKeyMapped annotation also specify it in the cache key configuration like this: ... Resolving this issue with a fix. > @AffinityKeyMapped ignored if QueryEntity used > -- > > Key: IGNITE-5795 > URL: https://issues.apache.org/jira/browse/IGNITE-5795 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Alexey Kukushkin > Fix For: 2.2 > > > When cache configured with QueryEntity and used key type with > @AffinityKeyMapped field, it will be ignored and wrong partition calculated. > This happens because QueryEntity processing precedes key type registering in > binary meta cache. On that step > CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve > type, so null returned and null putted in affKeyFields. > On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField > will return null from affKeyFields, but should be affinity key field. > Test that reproduces problem in [PR > 2330|https://github.com/apache/ignite/pull/2330] > To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it > will force registering key. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-5505) @AffinityKeyMapped annotation is ignored if class names are configured on BinaryConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin resolved IGNITE-5505.
--
Resolution: Workaround
See the comment above with a workaround provided
> @AffinityKeyMapped annotation is ignored if class names are configured on
> BinaryConfiguration
> -
>
> Key: IGNITE-5505
> URL: https://issues.apache.org/jira/browse/IGNITE-5505
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Andrey Gura
>Assignee: Alexey Kukushkin
> Fix For: 2.2
>
>
> {{@AffinityKeyMapped}} annotation on key class field is ignored in case when
> class names passed to {{inaryConfiguration}} via {{setClassNames()}} method.
> The problem is that Ignite uses {{IgniteConfiguration.cacheKeyCfg}} during
> {{BinaryContext.configure()}} execution and doesn't check class fileds on
> {{@AffinityKeyMapped}} annotation.
> Possible solution: check class fields on {{@AffinityKeyMapped}} annotation if
> there is no any mapping for cache key type.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5505) @AffinityKeyMapped annotation is ignored if class names are configured on BinaryConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114470#comment-16114470
]
Alexey Kukushkin commented on IGNITE-5505:
--
I discussed this with [~vozerov] again and confirmed we do not want to fix this
since any fix would violate Ignite design ideology.
To work around the problem in addition to specifying affinity key field using
@AffinityKeyMapped annotation also specify it in the cache key configuration
like this:
...
Resolving this issue with a fix.
> @AffinityKeyMapped annotation is ignored if class names are configured on
> BinaryConfiguration
> -
>
> Key: IGNITE-5505
> URL: https://issues.apache.org/jira/browse/IGNITE-5505
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Andrey Gura
>Assignee: Alexey Kukushkin
> Fix For: 2.2
>
>
> {{@AffinityKeyMapped}} annotation on key class field is ignored in case when
> class names passed to {{inaryConfiguration}} via {{setClassNames()}} method.
> The problem is that Ignite uses {{IgniteConfiguration.cacheKeyCfg}} during
> {{BinaryContext.configure()}} execution and doesn't check class fileds on
> {{@AffinityKeyMapped}} annotation.
> Possible solution: check class fields on {{@AffinityKeyMapped}} annotation if
> there is no any mapping for cache key type.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join
[ https://issues.apache.org/jira/browse/IGNITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5943: - Description: There is a race between a client join discovery event on server nodes and the moment when a client starts to establish outgoing communication connections. It would cause to rejecting communication connections on server nodes (for example. on requesting data from caches). The issue happens on really big topologies (> 300 nodes) or when many clients join simultaneously. was: There is a race between server nodes receive acknowledgment about joining client node and client node starts to think that it is absolutely functional. It would cause to rejecting communication (for example. on requesting data from caches) between the client and servers. The issue happens on really big topologies (> 300 nodes) or when many clients join simultaneously. > Communication. Server node may reject client connection during massive > clients join > --- > > Key: IGNITE-5943 > URL: https://issues.apache.org/jira/browse/IGNITE-5943 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.0 >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Critical > Fix For: 2.2 > > > There is a race between a client join discovery event on server nodes and the > moment when a client starts to establish outgoing communication connections. > It would cause to rejecting communication connections on server nodes (for > example. on requesting data from caches). > The issue happens on really big topologies (> 300 nodes) or when many clients > join simultaneously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join
[ https://issues.apache.org/jira/browse/IGNITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5943: - Summary: Communication. Server node may reject client connection during massive clients join (was: Communication. We could reject client connection while it has received EVT_NODE_JOINED) > Communication. Server node may reject client connection during massive > clients join > --- > > Key: IGNITE-5943 > URL: https://issues.apache.org/jira/browse/IGNITE-5943 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.0 >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Critical > Fix For: 2.2 > > > There is a race between server nodes receive acknowledgment about joining > client node and client node starts to think that it is absolutely functional. > It would cause to rejecting communication (for example. on requesting data > from caches) between the client and servers. > The issue happens on really big topologies (> 300 nodes) or when many clients > join simultaneously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5943) Communication. We could reject client connection while it has received EVT_NODE_JOINED
Eduard Shangareev created IGNITE-5943: - Summary: Communication. We could reject client connection while it has received EVT_NODE_JOINED Key: IGNITE-5943 URL: https://issues.apache.org/jira/browse/IGNITE-5943 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.0 Reporter: Eduard Shangareev Assignee: Eduard Shangareev Priority: Critical Fix For: 2.2 There is a race between server nodes receive acknowledgment about joining client node and client node starts to think that it is absolutely functional. It would cause to rejecting communication (for example. on requesting data from caches) between the client and servers. The issue happens on really big topologies (> 300 nodes) or when many clients join simultaneously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5942) Python3 pylibmc does not work with Ignite memcache mode
Mikhail Cherkasov created IGNITE-5942:
-
Summary: Python3 pylibmc does not work with Ignite memcache mode
Key: IGNITE-5942
URL: https://issues.apache.org/jira/browse/IGNITE-5942
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Cherkasov
Example from:
https://apacheignite.readme.io/v2.0/docs/memcached-support#python
doesn't for Python 3.6.
There's exception on the following call:
client.set("key", "val")
It was tested with another python library - it works, so looks like the problem
with pylibmc/libmemcached integration with Ignite.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5938) Implement WAL logs compaction and compression after checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-5938: --- Labels: Mak (was: ) > Implement WAL logs compaction and compression after checkpoint > -- > > Key: IGNITE-5938 > URL: https://issues.apache.org/jira/browse/IGNITE-5938 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Dmitriy Govorukhin > Fix For: 2.2 > > > Currently, we simply move WAL segments to archive when WAL segment is written > and delete when checkpoint history becomes too old. > Archived WAL segment contains physical delta records that are no longer > needed for rebalancing, so these records may be thrown away. In order to > optimize disk space and delta WAL rebalancing, we can do the following: > 1) Clean the WAL segments from the physical records > 2) Compress the cleaned segments (I expect this to be very effective since we > write full objects) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5938) Implement WAL logs compaction and compression after checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-5938: --- Labels: (was: Mak) > Implement WAL logs compaction and compression after checkpoint > -- > > Key: IGNITE-5938 > URL: https://issues.apache.org/jira/browse/IGNITE-5938 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Dmitriy Govorukhin > Fix For: 2.2 > > > Currently, we simply move WAL segments to archive when WAL segment is written > and delete when checkpoint history becomes too old. > Archived WAL segment contains physical delta records that are no longer > needed for rebalancing, so these records may be thrown away. In order to > optimize disk space and delta WAL rebalancing, we can do the following: > 1) Clean the WAL segments from the physical records > 2) Compress the cleaned segments (I expect this to be very effective since we > write full objects) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5941) Index with long name stores incorrect
Vladislav Pyatkov created IGNITE-5941:
-
Summary: Index with long name stores incorrect
Key: IGNITE-5941
URL: https://issues.apache.org/jira/browse/IGNITE-5941
Project: Ignite
Issue Type: Bug
Components: persistence
Reporter: Vladislav Pyatkov
SQL query by Index with long name return inconsistent result after cluster
restart and recover from storage. At the same time a query by other index (with
more shorter name) works correctly before and after recovery.
For example long index name:
{code}
QueryIndex index = new QueryIndex("name", true,
"COM.SBT.AZIMUTH_PSI.PUBLISHER.ENTITIES.PUB.PARTICLES.CARPORT#MODELCOM.SBT.AZIMUTH_PSI.PUBLISHER.ENTITIES.PUB.PARTICLES.CARPORT");
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5941) Index with long name stores incorrect
[
https://issues.apache.org/jira/browse/IGNITE-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-5941:
--
Affects Version/s: 2.1
> Index with long name stores incorrect
> -
>
> Key: IGNITE-5941
> URL: https://issues.apache.org/jira/browse/IGNITE-5941
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>
> SQL query by Index with long name return inconsistent result after cluster
> restart and recover from storage. At the same time a query by other index
> (with more shorter name) works correctly before and after recovery.
> For example long index name:
> {code}
> QueryIndex index = new QueryIndex("name", true,
> "COM.SBT.AZIMUTH_PSI.PUBLISHER.ENTITIES.PUB.PARTICLES.CARPORT#MODELCOM.SBT.AZIMUTH_PSI.PUBLISHER.ENTITIES.PUB.PARTICLES.CARPORT");
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5931:
---
Priority: Critical (was: Major)
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.2
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5918) Adding and searching objects in index tree produces a lot of garbage
[ https://issues.apache.org/jira/browse/IGNITE-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114413#comment-16114413 ] Igor Seliverstov commented on IGNITE-5918: -- [~yzhdanov], [~vozerov], could you look at the changes? > Adding and searching objects in index tree produces a lot of garbage > > > Key: IGNITE-5918 > URL: https://issues.apache.org/jira/browse/IGNITE-5918 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Igor Seliverstov > > Adding and searching objects in index tree produces a lot of garbage and this > can lead to big GC pauses. > Tests with data streaming of object with 5 string indexes show that ignite > server spends about 15-25% CPU time in GC. > The problem is that ignite deserialize objects for comparing, while for the > primitive type and strings comparing can be implemented for bytes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114414#comment-16114414
]
Pavel Tupitsyn commented on IGNITE-5931:
Another related problem: {{AffinityKeyMappedAttribute}} does not work with
dynamic type registration.
All of this stems from the fact that {{Marshaller}} code is a mess, we have two
{{AddUserType}} methods which work in a different way and duplicate some logic.
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5658) Optimizations for data streamer
[ https://issues.apache.org/jira/browse/IGNITE-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114411#comment-16114411 ] Igor Seliverstov commented on IGNITE-5658: -- [~yzhdanov], could you look at the changes? > Optimizations for data streamer > --- > > Key: IGNITE-5658 > URL: https://issues.apache.org/jira/browse/IGNITE-5658 > Project: Ignite > Issue Type: Improvement >Reporter: Yakov Zhdanov >Assignee: Igor Seliverstov > Labels: performance > Fix For: 2.2 > > Attachments: benchmark-full.properties > > > Data streamer can be improved with this: > -batch on per-partition basis and send batches to striped pool (for > allowOverwirte=false) > -New default - perNodeParallelOps should be twice CPU count of a remote node > (if not set by user, if set then parallelOps for every node is the value > provided by user) > -wait stable topology error should be output as warn -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-1577) IlligateStateException when removing index during stop
[
https://issues.apache.org/jira/browse/IGNITE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-1577.
-
Resolution: Won't Fix
Doesn't appear to be a problem.
> IlligateStateException when removing index during stop
> --
>
> Key: IGNITE-1577
> URL: https://issues.apache.org/jira/browse/IGNITE-1577
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Dmitriy Setrakyan
>Priority: Minor
> Labels: newbie
> Fix For: 2.2
>
>
> I ran string example which queries the streamed words onto 2 data nodes (2GB
> each, started with ExampleNodeStartup class), and while running, killed 1
> node. I also had 1 StreamWords and 1 QueryWords process.
> Got this error on the stopping node.
> {code}
> java.lang.IllegalStateException: Failed to remove from index (grid is
> stopping).
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:837)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:433)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.clearIndex(GridCacheMapEntry.java:3553)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:3374)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:117)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$CleanupWorker.body(GridCacheTtlManager.java:136)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (IGNITE-1577) IlligateStateException when removing index during stop
[
https://issues.apache.org/jira/browse/IGNITE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-1577.
---
> IlligateStateException when removing index during stop
> --
>
> Key: IGNITE-1577
> URL: https://issues.apache.org/jira/browse/IGNITE-1577
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Dmitriy Setrakyan
>Priority: Minor
> Labels: newbie
> Fix For: 2.2
>
>
> I ran string example which queries the streamed words onto 2 data nodes (2GB
> each, started with ExampleNodeStartup class), and while running, killed 1
> node. I also had 1 StreamWords and 1 QueryWords process.
> Got this error on the stopping node.
> {code}
> java.lang.IllegalStateException: Failed to remove from index (grid is
> stopping).
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:837)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:433)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.clearIndex(GridCacheMapEntry.java:3553)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:3374)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:117)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$CleanupWorker.body(GridCacheTtlManager.java:136)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5939) ODBC: SQLColAttributes should work with legacy attribute codes.
[
https://issues.apache.org/jira/browse/IGNITE-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114402#comment-16114402
]
ASF GitHub Bot commented on IGNITE-5939:
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/2399
IGNITE-5939: ODBC: SQLColAttributes now works with legacy attribute codes.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5939
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2399.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 #2399
commit 44496f38d6d55ab616e8a8cf4f7a8c986543ef66
Author: Igor Sapego
Date: 2017-08-04T13:55:05Z
IGNITE-5939: Added tests.
commit 8a443ced2071a9fff471ebd3167032708a3a4f16
Author: Igor Sapego
Date: 2017-08-04T13:57:05Z
IGNITE-5939: Fix
> ODBC: SQLColAttributes should work with legacy attribute codes.
> ---
>
> Key: IGNITE-5939
> URL: https://issues.apache.org/jira/browse/IGNITE-5939
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> According to
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function
>
> {quote}
> The #define values of the ODBC 2.x {{FieldIdentifiers}}
> {{SQL_COLUMN_LENGTH}}, {{SQL_COLUMN_PRECISION}}, and {{SQL_COLUMN_SCALE}} are
> different from the #define values of the ODBC 3.x {{FieldIdentifiers}}
> {{SQL_DESC_PRECISION}}, {{SQL_DESC_SCALE}}, and {{SQL_DESC_LENGTH}}. An ODBC
> 2.x driver need only support the ODBC 2.x values. An ODBC 3.x driver must
> support both "{{SQL_COLUMN}}" and "{{SQL_DESC}}" values for these three
> {{FieldIdentifiers}}. These values are different because precision, scale,
> and length are defined differently in ODBC 3.x than they were in ODBC 2.x.
> {quote}
> Currently, {{SQLColAttributes}} does not work with these three identifiers in
> our driver. Need to be fixed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown
[
https://issues.apache.org/jira/browse/IGNITE-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114398#comment-16114398
]
Vladimir Ozerov commented on IGNITE-5382:
-
[~skalashnikov], IMO this approach is prone to leaks. We have N threads, M
connection, and K statements. Only K is under our control at the moment. The
rest things can cause memory leaks if many client threads are used, and even
periodic cleanup would not help us.
May be would be better to merge both connections and statements as follows
(pseudocode):
1) Thread local statement cache
{code}
ThreadLocal cache;
{code}
2) Cache contains active connections with usage counters, and
Statement/Connection pairs:
{code}
class Cache {
Map> conns; // Map from schema name to
connection/counter.
Map, T2>; // Bounded map
from schema/SQL to connection/statement.
}
{code}
This way we will have N threads and K statement/connection pairs, which is more
predictable.
Thoughts?
> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
> Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command,
> which is rather expensive and may cause slowdown when queries form different
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be
> careful with concurrency and resource leaks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-425) Introduce transformers for continuous queries
[
https://issues.apache.org/jira/browse/IGNITE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16109140#comment-16109140
]
Nikolay Izhikov edited comment on IGNITE-425 at 8/4/17 1:50 PM:
PR - https://github.com/apache/ignite/pull/2372
US - http://reviews.ignite.apache.org/ignite/review/IGNT-CR-266
[~avinogradov] can you review my changes?
was (Author: nizhikov):
PR - https://github.com/apache/ignite/pull/2372
US - http://reviews.ignite.apache.org/ignite/review/IGNT-CR-254
[~avinogradov] can you review my changes?
> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
>
> Currently if updated entry passes the filter, it is sent to node initiated
> the query entirely. It would be good to provide user with the ability to
> transform entry and, for example, select only fields that are important. This
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} //
> Probably, we will have to introduce new listener type, since user may want to
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5912) [Redis] EXPIRE/PEXPIRE on keys
[ https://issues.apache.org/jira/browse/IGNITE-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114346#comment-16114346 ] Roman Shtykh commented on IGNITE-5912: -- Hi [~anovikov], Thanks for checking the pr. Modified as you pointed out. Many thanks! The only thing I have a question about is why `ExpireCommand.ttl` should be `long`? As I see all other commands have `ttl` as `Long`. > [Redis] EXPIRE/PEXPIRE on keys > -- > > Key: IGNITE-5912 > URL: https://issues.apache.org/jira/browse/IGNITE-5912 > Project: Ignite > Issue Type: New Feature >Reporter: Roman Shtykh >Assignee: Roman Shtykh > > https://redis.io/commands/expire > https://redis.io/commands/pexpire -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5940) DataStreamer throws exception as it's closed if OOM occurs on server node.
Mikhail Cherkasov created IGNITE-5940: - Summary: DataStreamer throws exception as it's closed if OOM occurs on server node. Key: IGNITE-5940 URL: https://issues.apache.org/jira/browse/IGNITE-5940 Project: Ignite Issue Type: Bug Affects Versions: 2.1 Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5384) JDBC Driver: implement ResultSet#getDate(int, Calendar)
[ https://issues.apache.org/jira/browse/IGNITE-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov reassigned IGNITE-5384: Assignee: Taras Ledkov > JDBC Driver: implement ResultSet#getDate(int, Calendar) > --- > > Key: IGNITE-5384 > URL: https://issues.apache.org/jira/browse/IGNITE-5384 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > > Current implementation doesn't use Calendar object to convert the date. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5939) ODBC: SQLColAttributes should work with legacy attribute codes.
[
https://issues.apache.org/jira/browse/IGNITE-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-5939:
Description:
According to
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function
{quote}
The #define values of the ODBC 2.x {{FieldIdentifiers}} {{SQL_COLUMN_LENGTH}},
{{SQL_COLUMN_PRECISION}}, and {{SQL_COLUMN_SCALE}} are different from the
#define values of the ODBC 3.x {{FieldIdentifiers}} {{SQL_DESC_PRECISION}},
{{SQL_DESC_SCALE}}, and {{SQL_DESC_LENGTH}}. An ODBC 2.x driver need only
support the ODBC 2.x values. An ODBC 3.x driver must support both
"{{SQL_COLUMN}}" and "{{SQL_DESC}}" values for these three
{{FieldIdentifiers}}. These values are different because precision, scale, and
length are defined differently in ODBC 3.x than they were in ODBC 2.x.
{quote}
Currently, {{SQLColAttributes}} does not work with these three identifiers in
our driver. Need to be fixed.
was:
According to
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function
The #define values of the ODBC 2.x {{FieldIdentifiers}} {{SQL_COLUMN_LENGTH}},
{{SQL_COLUMN_PRECISION}}, and {{SQL_COLUMN_SCALE}} are different from the
#define values of the ODBC 3.x {{FieldIdentifiers}} {{SQL_DESC_PRECISION}},
{{SQL_DESC_SCALE}}, and {{SQL_DESC_LENGTH}}. An ODBC 2.x driver need only
support the ODBC 2.x values. An ODBC 3.x driver must support both
"{{SQL_COLUMN}}" and "{{SQL_DESC}}" values for these three
{{FieldIdentifiers}}. These values are different because precision, scale, and
length are defined differently in ODBC 3.x than they were in ODBC 2.x.
Currently, {{SQLColAttributes}} does not work with these three identifiers in
our driver. Need to be fixed.
> ODBC: SQLColAttributes should work with legacy attribute codes.
> ---
>
> Key: IGNITE-5939
> URL: https://issues.apache.org/jira/browse/IGNITE-5939
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> According to
> https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function
>
> {quote}
> The #define values of the ODBC 2.x {{FieldIdentifiers}}
> {{SQL_COLUMN_LENGTH}}, {{SQL_COLUMN_PRECISION}}, and {{SQL_COLUMN_SCALE}} are
> different from the #define values of the ODBC 3.x {{FieldIdentifiers}}
> {{SQL_DESC_PRECISION}}, {{SQL_DESC_SCALE}}, and {{SQL_DESC_LENGTH}}. An ODBC
> 2.x driver need only support the ODBC 2.x values. An ODBC 3.x driver must
> support both "{{SQL_COLUMN}}" and "{{SQL_DESC}}" values for these three
> {{FieldIdentifiers}}. These values are different because precision, scale,
> and length are defined differently in ODBC 3.x than they were in ODBC 2.x.
> {quote}
> Currently, {{SQLColAttributes}} does not work with these three identifiers in
> our driver. Need to be fixed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5939) ODBC: SQLColAttributes should work with legacy attribute codes.
Igor Sapego created IGNITE-5939:
---
Summary: ODBC: SQLColAttributes should work with legacy attribute
codes.
Key: IGNITE-5939
URL: https://issues.apache.org/jira/browse/IGNITE-5939
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 2.1
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.2
According to
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlcolattribute-function
The #define values of the ODBC 2.x {{FieldIdentifiers}} {{SQL_COLUMN_LENGTH}},
{{SQL_COLUMN_PRECISION}}, and {{SQL_COLUMN_SCALE}} are different from the
#define values of the ODBC 3.x {{FieldIdentifiers}} {{SQL_DESC_PRECISION}},
{{SQL_DESC_SCALE}}, and {{SQL_DESC_LENGTH}}. An ODBC 2.x driver need only
support the ODBC 2.x values. An ODBC 3.x driver must support both
"{{SQL_COLUMN}}" and "{{SQL_DESC}}" values for these three
{{FieldIdentifiers}}. These values are different because precision, scale, and
length are defined differently in ODBC 3.x than they were in ODBC 2.x.
Currently, {{SQLColAttributes}} does not work with these three identifiers in
our driver. Need to be fixed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5921) Reduce contention for free list access
[ https://issues.apache.org/jira/browse/IGNITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-5921. -- Resolution: Duplicate > Reduce contention for free list access > -- > > Key: IGNITE-5921 > URL: https://issues.apache.org/jira/browse/IGNITE-5921 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Reduce contention for free list access. >Reporter: Mikhail Cherkasov >Assignee: Igor Seliverstov > > Reduce contention for free list access. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5921) Reduce contention for free list access
[ https://issues.apache.org/jira/browse/IGNITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114335#comment-16114335 ] Igor Seliverstov commented on IGNITE-5921: -- All works are done in scope of IGNITE-5658 > Reduce contention for free list access > -- > > Key: IGNITE-5921 > URL: https://issues.apache.org/jira/browse/IGNITE-5921 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Reduce contention for free list access. >Reporter: Mikhail Cherkasov >Assignee: Igor Seliverstov > > Reduce contention for free list access. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-3656) JdbcConnection.setTransactionIsolation should not throw an exception
[
https://issues.apache.org/jira/browse/IGNITE-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-3656.
-
Resolution: Duplicate
> JdbcConnection.setTransactionIsolation should not throw an exception
>
>
> Key: IGNITE-3656
> URL: https://issues.apache.org/jira/browse/IGNITE-3656
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>
> {{JdbcConnection.setTransactionIsolation}} now throws
> {{SQLFeatureNotSupportedException}} which looks incorrect, because:
> * This method can be called by a JDBC tool on startup, even if only select
> queries will be executed after that.
> * This method does not throw this exception according to JavaDoc.
> Other similar methods should be also revised.
> Corresponding user@ thread:
> http://apache-ignite-users.70518.x6.nabble.com/Stored-Procedure-td6548.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-4762) Support transactional updates in JDBC driver
[
https://issues.apache.org/jira/browse/IGNITE-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114333#comment-16114333
]
Vladimir Ozerov commented on IGNITE-4762:
-
NB: no TX support (or at least atomic updates) was added in the scope of this
ticket. Only {{transactionAllowed}} flag, which suppress exceptions.
> Support transactional updates in JDBC driver
>
>
> Key: IGNITE-4762
> URL: https://issues.apache.org/jira/browse/IGNITE-4762
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>
> Currently transactions are not supported by SQL and therefore by JDBC driver.
> However, it seems to be possible to provide support for multiple updates in a
> single transaction. We can add a special flag to JDBC driver to allow this.
> Any SELECT queries will still be executed out of transactional scope.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5918) Adding and searching objects in index tree produces a lot of garbage
[ https://issues.apache.org/jira/browse/IGNITE-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114324#comment-16114324 ] ASF GitHub Bot commented on IGNITE-5918: GitHub user gvvinblade opened a pull request: https://github.com/apache/ignite/pull/2398 IGNITE-5918 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5918 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2398.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 #2398 commit 8909ef69ab03c37b1bf99e25335b6f385f1ebbc3 Author: Igor Seliverstov Date: 2017-08-04T12:45:01Z IGNITE-5918 Adding and searching objects in index tree produces a lot of garbage > Adding and searching objects in index tree produces a lot of garbage > > > Key: IGNITE-5918 > URL: https://issues.apache.org/jira/browse/IGNITE-5918 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Igor Seliverstov > > Adding and searching objects in index tree produces a lot of garbage and this > can lead to big GC pauses. > Tests with data streaming of object with 5 string indexes show that ignite > server spends about 15-25% CPU time in GC. > The problem is that ignite deserialize objects for comparing, while for the > primitive type and strings comparing can be implemented for bytes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5658) Optimizations for data streamer
[ https://issues.apache.org/jira/browse/IGNITE-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-5658: Assignee: Igor Seliverstov (was: Yakov Zhdanov) > Optimizations for data streamer > --- > > Key: IGNITE-5658 > URL: https://issues.apache.org/jira/browse/IGNITE-5658 > Project: Ignite > Issue Type: Improvement >Reporter: Yakov Zhdanov >Assignee: Igor Seliverstov > Labels: performance > Fix For: 2.2 > > Attachments: benchmark-full.properties > > > Data streamer can be improved with this: > -batch on per-partition basis and send batches to striped pool (for > allowOverwirte=false) > -New default - perNodeParallelOps should be twice CPU count of a remote node > (if not set by user, if set then parallelOps for every node is the value > provided by user) > -wait stable topology error should be output as warn -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5658) Optimizations for data streamer
[ https://issues.apache.org/jira/browse/IGNITE-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114321#comment-16114321 ] ASF GitHub Bot commented on IGNITE-5658: GitHub user gvvinblade opened a pull request: https://github.com/apache/ignite/pull/2397 IGNITE-5658 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5658 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2397.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 #2397 commit 8909ef69ab03c37b1bf99e25335b6f385f1ebbc3 Author: Igor Seliverstov Date: 2017-08-04T12:45:01Z IGNITE-5918 Adding and searching objects in index tree produces a lot of garbage commit e6f7b3053fc29a0a6bdfd364b71709a72f920a12 Author: Igor Seliverstov Date: 2017-08-04T12:47:39Z IGNITE-5658 Optimizations for data streamer IGNITE-5921 Reduce contention for free list access > Optimizations for data streamer > --- > > Key: IGNITE-5658 > URL: https://issues.apache.org/jira/browse/IGNITE-5658 > Project: Ignite > Issue Type: Improvement >Reporter: Yakov Zhdanov >Assignee: Yakov Zhdanov > Labels: performance > Fix For: 2.2 > > Attachments: benchmark-full.properties > > > Data streamer can be improved with this: > -batch on per-partition basis and send batches to striped pool (for > allowOverwirte=false) > -New default - perNodeParallelOps should be twice CPU count of a remote node > (if not set by user, if set then parallelOps for every node is the value > provided by user) > -wait stable topology error should be output as warn -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114310#comment-16114310 ] Ryabov Dmitrii commented on IGNITE-602: --- Thx for answer, [~agura]. Should I add hashcode only when object is repeated or for every object when GridToStringBuilder read it first time? > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Artem Shutak >Assignee: Ryabov Dmitrii > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.2 > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-3479) Coordinator(s) for global transaction ordering
[ https://issues.apache.org/jira/browse/IGNITE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114262#comment-16114262 ] Semen Boikov edited comment on IGNITE-3479 at 8/4/17 12:30 PM: --- This assumes following tasks: - implement coordinator protocol (assign tx ID, return ID to use for query, etc) - implement coordinator assignment logic (assign automatically or using user-provided code/configuration) Most probably there should be special 'coordinator' role for node, so that this node should not execute other tasks. was (Author: sboikov): This assumes following tasks: - implement coordinator protocol (assign tx ID, return ID to use for query, etc) - implement coordinator assignment logic (assign automatically or using user-provided code/configuration) > Coordinator(s) for global transaction ordering > -- > > Key: IGNITE-3479 > URL: https://issues.apache.org/jira/browse/IGNITE-3479 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk >Assignee: Semen Boikov > Fix For: 2.2 > > > Current transaction ID will not work for SQL MVCC ordering because two > transaction IDs are not in total order across the cluster. > One of the approaches is to have a dedicated coordinator which will assign a > continuously growing transaction ID for each committed transaction. This ID > must be acquired by each transaction at the last step of PREPARE stage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5938) Implement WAL logs compaction and compression after checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-5938: -- Assignee: Dmitriy Govorukhin > Implement WAL logs compaction and compression after checkpoint > -- > > Key: IGNITE-5938 > URL: https://issues.apache.org/jira/browse/IGNITE-5938 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Dmitriy Govorukhin > Fix For: 2.2 > > > Currently, we simply move WAL segments to archive when WAL segment is written > and delete when checkpoint history becomes too old. > Archived WAL segment contains physical delta records that are no longer > needed for rebalancing, so these records may be thrown away. In order to > optimize disk space and delta WAL rebalancing, we can do the following: > 1) Clean the WAL segments from the physical records > 2) Compress the cleaned segments (I expect this to be very effective since we > write full objects) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5938) Implement WAL logs compaction and compression after checkpoint
Alexey Goncharuk created IGNITE-5938: Summary: Implement WAL logs compaction and compression after checkpoint Key: IGNITE-5938 URL: https://issues.apache.org/jira/browse/IGNITE-5938 Project: Ignite Issue Type: Improvement Components: persistence Affects Versions: 2.1 Reporter: Alexey Goncharuk Fix For: 2.2 Currently, we simply move WAL segments to archive when WAL segment is written and delete when checkpoint history becomes too old. Archived WAL segment contains physical delta records that are no longer needed for rebalancing, so these records may be thrown away. In order to optimize disk space and delta WAL rebalancing, we can do the following: 1) Clean the WAL segments from the physical records 2) Compress the cleaned segments (I expect this to be very effective since we write full objects) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-3484) MVCC data structure for getAll operation
[ https://issues.apache.org/jira/browse/IGNITE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3484: - Description: Need implement some data structure to store/get multiple entry versions: - committed value at first is stored in separate data structure (there also need store related tx id to filter out data for non-finished transactions), probably existing BPlusTree can be used - periodically need flush data for finished transaction in 'main' hash index - 'getAll' operation should include max 'visible' ID and list of active transactions, this information should be used to find last 'visible' version in 'mvcc' or 'main' index was: We need to make sure that SQL queries are executed on a certain in-memory timestamp or version. This will require having as many versions of data in memory as needed by the ongoing SQL queries. Once the queries complete, the older versions should be discarded. TBD: design requirements for MVCC. > MVCC data structure for getAll operation > > > Key: IGNITE-3484 > URL: https://issues.apache.org/jira/browse/IGNITE-3484 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk > Fix For: 2.2 > > > Need implement some data structure to store/get multiple entry versions: > - committed value at first is stored in separate data structure (there also > need store related tx id to filter out data for non-finished transactions), > probably existing BPlusTree can be used > - periodically need flush data for finished transaction in 'main' hash index > - 'getAll' operation should include max 'visible' ID and list of active > transactions, this information should be used to find last 'visible' version > in 'mvcc' or 'main' index -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown
[
https://issues.apache.org/jira/browse/IGNITE-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114290#comment-16114290
]
Sergey Kalashnikov commented on IGNITE-5382:
[~vozerov]
When thread closes its connection or changes schema on it, all the statements
in the thread's statement cache become invalid and we remove them.
Managing both connection and all its statements as a whole seems to be a good
idea becouse of the above.
> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
> Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command,
> which is rather expensive and may cause slowdown when queries form different
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be
> careful with concurrency and resource leaks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-3484) MVCC data structure for getAll operation
[ https://issues.apache.org/jira/browse/IGNITE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3484: - Summary: MVCC data structure for getAll operation (was: MVCC for cache data structures) > MVCC data structure for getAll operation > > > Key: IGNITE-3484 > URL: https://issues.apache.org/jira/browse/IGNITE-3484 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk > Fix For: 2.2 > > > We need to make sure that SQL queries are executed on a certain in-memory > timestamp or version. This will require having as many versions of data in > memory as needed by the ongoing SQL queries. Once the queries complete, the > older versions should be discarded. > TBD: design requirements for MVCC. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114287#comment-16114287
]
Andrey Gura edited comment on IGNITE-602 at 8/4/17 12:13 PM:
-
Hi, [~SomeFire]
I think we can improve a couple of things in this implementation^
1. Need to avoid double look up of value from {{IdentityHashMap}} (the first -
{{isSaved()}} method, and the second - {{getPostion()}}). One call of map.get()
is enough.
2. It's hard enough to identify what exactly object referenced by {{\{position
N\}}} expression. Better solution is referenced object label. For example
result string will be look like this
{{Node@62101a6c \[name=n1, next=Node \[name=n2, next=Node \[name=n3,
next=Node@62101a6c\]]]}} where label starts with {{@}} character and represent
hex string of identity hash code:
{{Integer.toHexString(System.identityHashCode(some_obj))}}.
Could you please tests that checks that resulting string is correct because in
current implementation index calculation is wrong.
Also please fix code style issues.
was (Author: agura):
Hi, [~SomeFire]
I think we can improve a couple of things in this implementation^
1. Need to avoid double look up of value from {{IdentityHashMap}} (the first -
{{isSaved()}} method, and the second - {{getPostion()}}). One call of map.get()
is enough.
2. It's hard enough to identify what exactly object referenced by {{\{position
N\}}} expression. Better solution is referenced object label. For example
result string will be look like this
{{Node@62101a6c \[name=n1, next=Node \[name=n2, next=Node \[name=n3,
next=Node@62101a6c\]]]}} where label starts with {{@}} character and represent
hex string of identity hash code:
{{Integer.toHexString(System.identityHashCode(some_obj))}}.
Also please fix code style issues.
> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by
> infinite recursion
>
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
>
> See test
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
> and related TODO in same source file.
> Also take a look at
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5936) Cleanup of not needed and committed versions
[ https://issues.apache.org/jira/browse/IGNITE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-5936: - Description: At first committed data is stored in separate data structure.Need implement some procedure to remove from mvcc storage versions which are not needed anymore and flush committed versions in main storage. Version which is safe to remove (there are not readers using this version) should be somehow passed from coordinator to servers. (was: Need implement some procedure to remove from mvcc storage versions which are not needed anymore. Version which is safe to remove (there are not readers using this version) should be somehow passed from coordinator to servers.) > Cleanup of not needed and committed versions > > > Key: IGNITE-5936 > URL: https://issues.apache.org/jira/browse/IGNITE-5936 > Project: Ignite > Issue Type: Sub-task > Components: cache, sql >Reporter: Semen Boikov > Fix For: 2.2 > > > At first committed data is stored in separate data structure.Need implement > some procedure to remove from mvcc storage versions which are not needed > anymore and flush committed versions in main storage. Version which is safe > to remove (there are not readers using this version) should be somehow passed > from coordinator to servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5937) Mvcc data structure for SQL queries
Semen Boikov created IGNITE-5937: Summary: Mvcc data structure for SQL queries Key: IGNITE-5937 URL: https://issues.apache.org/jira/browse/IGNITE-5937 Project: Ignite Issue Type: Sub-task Reporter: Semen Boikov Need implement some data structure to store/query multiple entry versions. One possible option: - committed value at first is stored in separate BPlusTree index (there also need store related tx id to filter out data for non-finished transactions) - periodically flush data for finished transaction in 'main' index - for SQL queries need merge result from main index and filtered 'mvcc' index. Note: it is possible 'mvcc' index will contain multiple committed versions of the same entry, need make sure only one last one will appear in result. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5936) Cleanup of not needed and committed versions
[ https://issues.apache.org/jira/browse/IGNITE-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-5936: - Summary: Cleanup of not needed and committed versions (was: Cleanup of not needed versions) > Cleanup of not needed and committed versions > > > Key: IGNITE-5936 > URL: https://issues.apache.org/jira/browse/IGNITE-5936 > Project: Ignite > Issue Type: Sub-task > Components: cache, sql >Reporter: Semen Boikov > Fix For: 2.2 > > > Need implement some procedure to remove from mvcc storage versions which are > not needed anymore. Version which is safe to remove (there are not readers > using this version) should be somehow passed from coordinator to servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114287#comment-16114287
]
Andrey Gura commented on IGNITE-602:
Hi, [~SomeFire]
I think we can improve a couple of things in this implementation^
1. Need to avoid double look up of value from {{IdentityHashMap}} (the first -
{{isSaved()}} method, and the second - {{getPostion()}}). One call of map.get()
is enough.
2. It's hard enough to identify what exactly object referenced by {{\{position
N\}}} expression. Better solution is referenced object label. For example
result string will be look like this
{{Node@62101a6c \[name=n1, next=Node \[name=n2, next=Node \[name=n3,
next=Node@62101a6c\]]]}} where label starts with {{@}} character and represent
hex string of identity hash code:
{{Integer.toHexString(System.identityHashCode(some_obj))}}.
Also please fix code style issues.
> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by
> infinite recursion
>
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.2
>
>
> See test
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
> and related TODO in same source file.
> Also take a look at
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5932) Integrate communication with coordinator in tx protocol
[ https://issues.apache.org/jira/browse/IGNITE-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-5932: - Description: Need integrate communication with coordinator in transactions protocol: - reading transaction need request read ID from coordinator - after locks are acquired need request ID from coordinator - this ID should be passed to primary/backups and passed to update - after tx is committed need notify coordinator (note: need make sure that this notification is processed in such way so that thread executed transaction will see all his changes) Notes: - there are differences in prepare logic for optimistic/pessimistic/serializable transactions, so most probably work with coordinator should be implemented separately for these tx types - need support case when coordinator fails during prepare (need think is necessary rollback and retry tx or switch to next assigned coordinator) was: Need integrate communication with coordinator in transactions protocol: - after locks are acquired need request ID from coordinator - this ID should be passed to primary/backups and passed to update - after tx is committed need notify coordinator Notes: - there are differences in prepare logic for optimistic/pessimistic/serializable transactions, so most probably work with coordinator should be implemented separately for these tx types - need support case when coordinator fails during prepare (need think is necessary rollback and retry tx or switch to next assigned coordinator) > Integrate communication with coordinator in tx protocol > --- > > Key: IGNITE-5932 > URL: https://issues.apache.org/jira/browse/IGNITE-5932 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 2.2 > > > Need integrate communication with coordinator in transactions protocol: > - reading transaction need request read ID from coordinator > - after locks are acquired need request ID from coordinator > - this ID should be passed to primary/backups and passed to update > - after tx is committed need notify coordinator (note: need make sure that > this notification is processed in such way so that thread executed > transaction will see all his changes) > Notes: > - there are differences in prepare logic for > optimistic/pessimistic/serializable transactions, so most probably work with > coordinator should be implemented separately for these tx types > - need support case when coordinator fails during prepare (need think is > necessary rollback and retry tx or switch to next assigned coordinator) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations
[ https://issues.apache.org/jira/browse/IGNITE-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Tikhonov resolved IGNITE-5290. -- Resolution: Fixed Fixed by 42293fa sboikov on 29.05.2017 at 16:41 > Events might be missed during concurrent CQ registration and cache operations > - > > Key: IGNITE-5290 > URL: https://issues.apache.org/jira/browse/IGNITE-5290 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Nikolay Tikhonov >Assignee: Nikolay Tikhonov > Attachments: test.patch > > > Events might be missed during concurrent CQ registration and cache > operations. See attached test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5936) Cleanup of not needed versions
Semen Boikov created IGNITE-5936: Summary: Cleanup of not needed versions Key: IGNITE-5936 URL: https://issues.apache.org/jira/browse/IGNITE-5936 Project: Ignite Issue Type: Sub-task Reporter: Semen Boikov Need implement some procedure to remove from mvcc storage versions which are not needed anymore. Version which is safe to remove (there are not readers using this version) should be somehow passed from coordinator to servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114273#comment-16114273
]
Pavel Tupitsyn commented on IGNITE-5931:
Another problem is that we return {{BinarySurrogateTypeDescriptor}} from
{{GetDescriptor}} when the type has not been found. I think we should proceed
with dynamic registration if typeName is known.
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown
[
https://issues.apache.org/jira/browse/IGNITE-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114270#comment-16114270
]
Vladimir Ozerov commented on IGNITE-5382:
-
[~skalashnikov], [~al.psc], any reason why we add statement cache to
{{H2ConnectionWrapper}}?
> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
> Labels: important, performance
> Fix For: 2.2
>
>
> We have thread-bound cached connection to H2 database which is bound to
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command,
> which is rather expensive and may cause slowdown when queries form different
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be
> careful with concurrency and resource leaks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5935) Integrate mvcc support in tx recovery protocol
Semen Boikov created IGNITE-5935: Summary: Integrate mvcc support in tx recovery protocol Key: IGNITE-5935 URL: https://issues.apache.org/jira/browse/IGNITE-5935 Project: Ignite Issue Type: Sub-task Reporter: Semen Boikov Need make sure tx recovery work properly with mvcc enabled: - tx IDs are generated and not lost if transaction is committed by recovery procedure - tx should be removed from list of active transactions on coordinator -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5233) JDBC thin Driver: implement metadata support
[ https://issues.apache.org/jira/browse/IGNITE-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114231#comment-16114231 ] Taras Ledkov edited comment on IGNITE-5233 at 8/4/17 11:32 AM: --- I've re-merged patch with master. [~skalashnikov], [~al.psc] , please review the patch. was (Author: tledkov-gridgain): I've re-merged patch with master. [~vozerov], please review the patch. > JDBC thin Driver: implement metadata support > - > > Key: IGNITE-5233 > URL: https://issues.apache.org/jira/browse/IGNITE-5233 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5934) Integrate mvcc support in sql query protocol
Semen Boikov created IGNITE-5934: Summary: Integrate mvcc support in sql query protocol Key: IGNITE-5934 URL: https://issues.apache.org/jira/browse/IGNITE-5934 Project: Ignite Issue Type: Sub-task Reporter: Semen Boikov Need integrate mvcc support in sql query protocol: - request current ID and list of active txs from coordinator - pass this info in sql requests and in sql queries - notify coordinator after query completed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5930) Long running transactions while load test with 1 memory policy, 14 caches and >=24 servers
[ https://issues.apache.org/jira/browse/IGNITE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ksenia Rybakova updated IGNITE-5930: Affects Version/s: (was: 1.9) 2.1 > Long running transactions while load test with 1 memory policy, 14 caches and > >=24 servers > -- > > Key: IGNITE-5930 > URL: https://issues.apache.org/jira/browse/IGNITE-5930 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ksenia Rybakova > Attachments: ignite-base-load-config.xml, run-load.properties, > run-load.xml > > > Load config: > - CacheRandomOperation benchmark > - Caches: > atomic partitioned cache > 2 tx partitioned caches > 2 atomic partitioned onheap caches > 2 atomic replicated onheap caches > 2 tx partitioned onheap caches > 2 tx replicated onheap caches > 3 partitioned atomic indexed caches > - 1 default memory policy is used > - Preload amount: 500K-2.5M entries per cache > - Key range: 1M > - Persistent store is disabled > - 24 server nodes or more (3 nodes per physical host), 16 client nodes > Long running transactions occur after preloading and throughput dropps to 0. > Note, that with 16 server nodes transactions are ok. > Complete configs are attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5933) Integrate mvcc support in cache.getAll protocol
Semen Boikov created IGNITE-5933: Summary: Integrate mvcc support in cache.getAll protocol Key: IGNITE-5933 URL: https://issues.apache.org/jira/browse/IGNITE-5933 Project: Ignite Issue Type: Sub-task Reporter: Semen Boikov Need integrate mvcc support in cache.getAll protocol: - request current ID and list of active txs from coordinator - pass this info in get requests and in local 'get' - notify coordinator after getAll completed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5930) Long running transactions while load test with 1 memory policy, 14 caches and >=24 servers
[ https://issues.apache.org/jira/browse/IGNITE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ksenia Rybakova updated IGNITE-5930: Attachment: ignite-base-load-config.xml run-load.xml run-load.properties > Long running transactions while load test with 1 memory policy, 14 caches and > >=24 servers > -- > > Key: IGNITE-5930 > URL: https://issues.apache.org/jira/browse/IGNITE-5930 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Ksenia Rybakova > Attachments: ignite-base-load-config.xml, run-load.properties, > run-load.xml > > > Load config: > - CacheRandomOperation benchmark > - Caches: > atomic partitioned cache > 2 tx partitioned caches > 2 atomic partitioned onheap caches > 2 atomic replicated onheap caches > 2 tx partitioned onheap caches > 2 tx replicated onheap caches > 3 partitioned atomic indexed caches > - 1 default memory policy is used > - Preload amount: 500K-2.5M entries per cache > - Key range: 1M > - Persistent store is disabled > - 24 server nodes or more (3 nodes per physical host), 16 client nodes > Long running transactions occur after preloading and throughput dropps to 0. > Note, that with 16 server nodes transactions are ok. > Complete configs are attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-3479) Coordinator(s) for global transaction ordering
[ https://issues.apache.org/jira/browse/IGNITE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114262#comment-16114262 ] Semen Boikov commented on IGNITE-3479: -- This assumes following tasks: - implement coordinator protocol (assign tx ID, return ID to use for query, etc) - implement coordinator assignment logic (assign automatically or using user-provided code/configuration) > Coordinator(s) for global transaction ordering > -- > > Key: IGNITE-3479 > URL: https://issues.apache.org/jira/browse/IGNITE-3479 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk >Assignee: Semen Boikov > Fix For: 2.2 > > > Current transaction ID will not work for SQL MVCC ordering because two > transaction IDs are not in total order across the cluster. > One of the approaches is to have a dedicated coordinator which will assign a > continuously growing transaction ID for each committed transaction. This ID > must be acquired by each transaction at the last step of PREPARE stage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-3479) Coordinator(s) for global transaction ordering
[ https://issues.apache.org/jira/browse/IGNITE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov reassigned IGNITE-3479: Assignee: Semen Boikov > Coordinator(s) for global transaction ordering > -- > > Key: IGNITE-3479 > URL: https://issues.apache.org/jira/browse/IGNITE-3479 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk >Assignee: Semen Boikov > Fix For: 2.2 > > > Current transaction ID will not work for SQL MVCC ordering because two > transaction IDs are not in total order across the cluster. > One of the approaches is to have a dedicated coordinator which will assign a > continuously growing transaction ID for each committed transaction. This ID > must be acquired by each transaction at the last step of PREPARE stage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5932) Integrate communication with coordinator in tx protocol
Semen Boikov created IGNITE-5932: Summary: Integrate communication with coordinator in tx protocol Key: IGNITE-5932 URL: https://issues.apache.org/jira/browse/IGNITE-5932 Project: Ignite Issue Type: Sub-task Components: cache Reporter: Semen Boikov Assignee: Semen Boikov Need integrate communication with coordinator in transactions protocol: - after locks are acquired need request ID from coordinator - this ID should be passed to primary/backups and passed to update - after tx is committed need notify coordinator Notes: - there are differences in prepare logic for optimistic/pessimistic/serializable transactions, so most probably work with coordinator should be implemented separately for these tx types - need support case when coordinator fails during prepare (need think is necessary rollback and retry tx or switch to next assigned coordinator) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5931) .NET: Incorrect conflicting type error
Pavel Tupitsyn created IGNITE-5931:
--
Summary: .NET: Incorrect conflicting type error
Key: IGNITE-5931
URL: https://issues.apache.org/jira/browse/IGNITE-5931
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.2
Incorrect conflicting type error can occur when registering the same time from
multiple threads simultaneously:
{code}
Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
{code}
{{Marshaller.AddType}} should check if existing type is the same as new one (as
we do it in {{AddUserType}}, see other usages of {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5930) Long running transactions while load test with 1 memory policy, 14 caches and >=24 servers
[ https://issues.apache.org/jira/browse/IGNITE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ksenia Rybakova updated IGNITE-5930: Description: Load config: - CacheRandomOperation benchmark - Caches: atomic partitioned cache 2 tx partitioned caches 2 atomic partitioned onheap caches 2 atomic replicated onheap caches 2 tx partitioned onheap caches 2 tx replicated onheap caches 3 partitioned atomic indexed caches - 1 default memory policy is used - Preload amount: 500K-2.5M entries per cache - Key range: 1M - Persistent store is disabled - 24 server nodes or more (3 nodes per physical host), 16 client nodes Long running transactions occur after preloading and throughput dropps to 0. Note, that with 16 server nodes transactions are ok. Complete configs are attached. was: Load config: - CacheRandomOperation benchmark - Caches: atomic partitioned cache 2 tx partitioned caches 2 atomic partitioned onheap caches 2 atomic replicated onheap caches 2 tx partitioned onheap caches 2 tx replicated onheap caches 3 partitioned atomic indexed caches - Preload amount: 500K-2.5M entries per cache - Key range: 1M - Persistent store is disabled - 24 server nodes or more (3 nodes per physical host), 16 client nodes Long running transactions occur after preloading and throughput dropps to 0. Note, that with 16 server nodes transactions are ok. Complete configs are attached. > Long running transactions while load test with 1 memory policy, 14 caches and > >=24 servers > -- > > Key: IGNITE-5930 > URL: https://issues.apache.org/jira/browse/IGNITE-5930 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Ksenia Rybakova > > Load config: > - CacheRandomOperation benchmark > - Caches: > atomic partitioned cache > 2 tx partitioned caches > 2 atomic partitioned onheap caches > 2 atomic replicated onheap caches > 2 tx partitioned onheap caches > 2 tx replicated onheap caches > 3 partitioned atomic indexed caches > - 1 default memory policy is used > - Preload amount: 500K-2.5M entries per cache > - Key range: 1M > - Persistent store is disabled > - 24 server nodes or more (3 nodes per physical host), 16 client nodes > Long running transactions occur after preloading and throughput dropps to 0. > Note, that with 16 server nodes transactions are ok. > Complete configs are attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5930) Long running transactions while load test with 1 memory policy, 14 caches and >=24 servers
Ksenia Rybakova created IGNITE-5930: --- Summary: Long running transactions while load test with 1 memory policy, 14 caches and >=24 servers Key: IGNITE-5930 URL: https://issues.apache.org/jira/browse/IGNITE-5930 Project: Ignite Issue Type: Bug Affects Versions: 1.9 Reporter: Ksenia Rybakova Load config: - CacheRandomOperation benchmark - Caches: atomic partitioned cache 2 tx partitioned caches 2 atomic partitioned onheap caches 2 atomic replicated onheap caches 2 tx partitioned onheap caches 2 tx replicated onheap caches 3 partitioned atomic indexed caches - Preload amount: 500K-2.5M entries per cache - Key range: 1M - Persistent store is disabled - 24 server nodes or more (3 nodes per physical host), 16 client nodes Long running transactions occur after preloading and throughput dropps to 0. Note, that with 16 server nodes transactions are ok. Complete configs are attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5929) Add application name to query
Alexey Kuznetsov created IGNITE-5929: Summary: Add application name to query Key: IGNITE-5929 URL: https://issues.apache.org/jira/browse/IGNITE-5929 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.1 Reporter: Alexey Kuznetsov Fix For: 2.2 It will be useful feature to add application name to query. This will allow to understand from logs and UI tools what application executed some query. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5648) NOT NULL constraint support for CREATE TABLE operator
[
https://issues.apache.org/jira/browse/IGNITE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5648:
Fix Version/s: (was: 2.3)
2.2
> NOT NULL constraint support for CREATE TABLE operator
> -
>
> Key: IGNITE-5648
> URL: https://issues.apache.org/jira/browse/IGNITE-5648
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Sergey Kalashnikov
> Fix For: 2.2
>
>
> This is an umbrella ticket intended to aggregate all the activities related
> to {{NOT NULL}} constraint support for {{CREATE TABLE}} commands.
> {code}
> CREATE TABLE legs(legid INT NOT NULL);
> {code}
> Ignite must prevent setting {{legid}} to {{null}} value.
> The feature has to be supported for:
> * ODBC and JDBC drivers.
> * Native APIs (Java, .NET, C++)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-3478) Transactional SQL (mvcc)
[ https://issues.apache.org/jira/browse/IGNITE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3478: - Summary: Transactional SQL (mvcc) (was: Transactional SQL) > Transactional SQL (mvcc) > > > Key: IGNITE-3478 > URL: https://issues.apache.org/jira/browse/IGNITE-3478 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Alexey Goncharuk >Assignee: Semen Boikov > Labels: important > Fix For: 2.2 > > > Current Ignite SQL does not take into account transaction boundaries. For > example, if a transaction atomically changes balance of two accounts, then a > concurrent SQL query can see partially committed transaction. This works for > data analytics, but does not work for more strict and demanding scenarios. > It would be perfect if we had a mode which ensures transaction boundaries are > taken into account for SQL query. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5233) JDBC thin Driver: implement metadata support
[ https://issues.apache.org/jira/browse/IGNITE-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114231#comment-16114231 ] Taras Ledkov commented on IGNITE-5233: -- I've re-merged patch with master. [~vozerov], please review the patch. > JDBC thin Driver: implement metadata support > - > > Key: IGNITE-5233 > URL: https://issues.apache.org/jira/browse/IGNITE-5233 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
