[jira] [Commented] (IGNITE-12016) Is there option to increase or decrease Ignite SQL Table backup count after its initialized?
[ https://issues.apache.org/jira/browse/IGNITE-12016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893366#comment-16893366 ] Ivan Pavlukhin commented on IGNITE-12016: - Hi [~hirik], I am not aware of such feature. Consider using _user mailing list_ for asking questions. You can find instructions at the very top of https://ignite.apache.org/community/resources.html > Is there option to increase or decrease Ignite SQL Table backup count after > its initialized? > > > Key: IGNITE-12016 > URL: https://issues.apache.org/jira/browse/IGNITE-12016 > Project: Ignite > Issue Type: New Feature >Reporter: hirik >Priority: Major > > Hi, > We are working in a dynamic environment, based on the new nodes we should > update the backup count of existing SQL tables. is there any api available to > support this requirement? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page
[ https://issues.apache.org/jira/browse/IGNITE-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-11353. - > Web console: responses with status 401 do not redirect to signin page > - > > Key: IGNITE-11353 > URL: https://issues.apache.org/jira/browse/IGNITE-11353 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 16m > Remaining Estimate: 0h > > What happens: > On page reload, when backend API responds with status of 401, the app is > stuck on "loading" screen and does not redirect to signin screen. > What should happen: > The app should redirect to signin screen when 401 happens (except for a few > exceptions). > How to reproduce: > 1. Sign out. > 2. Open profile page URL (/settings/profile). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
[
https://issues.apache.org/jira/browse/IGNITE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893344#comment-16893344
]
Ignite TC Bot commented on IGNITE-3195:
---
{panel:title=Branch: [pull/6688/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4394852&buildTypeId=IgniteTests24Java8_RunAll]
> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-16
> Fix For: 2.8
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Presently it's considered that the maximum number of threads that has to
> process all demand and supply messages coming from all the nodes must not be
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages,
> that correspond to a particular topic, are processed in parallel for
> different nodes. Refer to the implementation of
> {{GridIoManager.processOrderedMessage}} to see that for every topic there
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2456)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1179)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1148)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> All this means that in fact the number of threads that will be busy with
> replication activity will be equal to
> {{IgniteConfiguration.rebalanceThreadPoolSize}} x
> number_of_nodes_participated_in_rebalancing
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12019) [TC Bot] PR screen resets the base branch on page refresh
[ https://issues.apache.org/jira/browse/IGNITE-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12019: -- Ignite Flags: (was: Docs Required) > [TC Bot] PR screen resets the base branch on page refresh > - > > Key: IGNITE-12019 > URL: https://issues.apache.org/jira/browse/IGNITE-12019 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Even though 'baseBranchForTc' is already supported by the page, it is not > picked up because the initial value is '' and the URL is not updated when > select is updated. > I suggest to update the URL on select change using history object. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12019) [TC Bot] PR screen resets the base branch on page refresh
[ https://issues.apache.org/jira/browse/IGNITE-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893327#comment-16893327 ] Alexey Goncharuk commented on IGNITE-12019: --- [~dpavlov] can you please take a look at this simple fix? > [TC Bot] PR screen resets the base branch on page refresh > - > > Key: IGNITE-12019 > URL: https://issues.apache.org/jira/browse/IGNITE-12019 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Even though 'baseBranchForTc' is already supported by the page, it is not > picked up because the initial value is '' and the URL is not updated when > select is updated. > I suggest to update the URL on select change using history object. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (IGNITE-12019) [TC Bot] PR screen resets the base branch on page refresh
[ https://issues.apache.org/jira/browse/IGNITE-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-12019: - Assignee: Alexey Goncharuk > [TC Bot] PR screen resets the base branch on page refresh > - > > Key: IGNITE-12019 > URL: https://issues.apache.org/jira/browse/IGNITE-12019 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > > Even though 'baseBranchForTc' is already supported by the page, it is not > picked up because the initial value is '' and the URL is not updated when > select is updated. > I suggest to update the URL on select change using history object. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12019) [TC Bot] PR screen resets the base branch on page refresh
Alexey Goncharuk created IGNITE-12019: - Summary: [TC Bot] PR screen resets the base branch on page refresh Key: IGNITE-12019 URL: https://issues.apache.org/jira/browse/IGNITE-12019 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk Even though 'baseBranchForTc' is already supported by the page, it is not picked up because the initial value is '' and the URL is not updated when select is updated. I suggest to update the URL on select change using history object. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
[ https://issues.apache.org/jira/browse/IGNITE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893189#comment-16893189 ] Shane commented on IGNITE-9033: --- Also needed in the Java thin client. Please. > .NET: specify expiry policy when creating cache using thin client > - > > Key: IGNITE-9033 > URL: https://issues.apache.org/jira/browse/IGNITE-9033 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > > Need to add ability to create dynamic caches specifying expiry policy with > thin client. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12018) Web Agent docker image: 'functions.sh' not found
Igor Belyakov created IGNITE-12018:
--
Summary: Web Agent docker image: 'functions.sh' not found
Key: IGNITE-12018
URL: https://issues.apache.org/jira/browse/IGNITE-12018
Project: Ignite
Issue Type: Bug
Components: UI
Affects Versions: 2.7.5, 2.7
Reporter: Igor Belyakov
Steps to reproduce:
1. Build docker image by using "docker/web-agent/Dockerfile" according to
README file.
2. Start docker container by using generated image.
3. Next error happens on container start:
{code:java}
./ignite-web-agent.sh: line 39:
/opt/ignite/ignite-web-agent/include/functions.sh: No such file or directory
./ignite-web-agent.sh: line 44: checkJava: command not found
./ignite-web-agent.sh: line 64: javaMajorVersion: command not found
./ignite-web-agent.sh: line 66: [: -eq: unary operator expected
./ignite-web-agent.sh: line 71: [: -gt: unary operator expected
./ignite-web-agent.sh: line 84: [: -eq: unary operator expected
./ignite-web-agent.sh: line 95: : command not found{code}
Image contains next files in "/opt/ignite/ignite-web-agent" directory without
any sub directories:
{code:java}
-rw-r--r-- 1 root root 89 Dec 4 2018 README.txt
-rw-r--r-- 1 root root 8080 Dec 4 2018 db-init.sql
-rw-rw-r-- 1 root root 203 Jul 25 12:30 default.properties
-rwxr-xr-x 1 root root 2721 Dec 4 2018 functions.sh
-rw-r--r-- 1 root root 29118502 Dec 6 2018 ignite-web-agent-2.7.0.jar
-rw-r--r-- 1 root root 4590 Dec 4 2018 ignite-web-agent.bat
-rw-rw-r-- 1 root root 561 Jul 25 16:31 ignite-web-agent.log
-rwxr-xr-x 1 root root 3229 Jul 25 16:33 ignite-web-agent.sh
{code}
The issue happens during executing files copy command in Dockerfile, it doesn't
keep directories structure. To solve this problem "COPY ignite-web-agent*/* ./"
command should be changed to "COPY ignite-web-agent* ./"
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12015) Text caseinsensitive search
[ https://issues.apache.org/jira/browse/IGNITE-12015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893046#comment-16893046 ] hirik commented on IGNITE-12015: [~Pavlukhin] thanks for the update. Sure, we can resolve this ticket. > Text caseinsensitive search > > > Key: IGNITE-12015 > URL: https://issues.apache.org/jira/browse/IGNITE-12015 > Project: Ignite > Issue Type: Improvement >Reporter: hirik >Priority: Critical > > Hi, > I'm looking for > [VARCHAR_IGNORECASE|http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type] > kind of datatype in Ignite SQL for text ignore-case search. Is there any > reason for this not available in Ignite even though Apache Ignite SQL engine > is tightly coupled with H2 database? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-5555) Ignite PDS 1: JVM crash on teamcity (Rare)
[
https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov resolved IGNITE-.
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.8)
> Ignite PDS 1: JVM crash on teamcity (Rare)
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, test-fail
> Attachments: crash_report, hs_err_pid7100.log.txt, thread_dump
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Most recent crashes
> https://ci.ignite.apache.org/viewLog.html?buildId=1095007&buildTypeId=IgniteTests24Java8_IgnitePds1&tab=buildResultsDiv
> {noformat}
>Ignite PDS 1 [ tests 0 JVM CRASH ]
> BPlusTreeReuseListPageMemoryImplTest.testEmptyCursors (last started)
> {noformat}
> https://ci.ignite.apache.org/viewLog.html?buildId=1086130&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgnitePds1
> {noformat}
>Ignite PDS 1 [ tests 0 JVM CRASH ]
> BPlusTreeReuseListPageMemoryImplTest.testEmptyCursors (last started)
> {noformat}
> (older failure
> http://ci.ignite.apache.org/viewLog.html?buildId=675694&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgnitePds1#)
> Stacktrace indicates failure was in ignite code related to B+tree
> {noformat}J 34156 C2
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.readLockPage(JLorg/apache/ignite/internal/pagemem/FullPageId;ZZ)J
> (88 bytes) @ 0x7f98cfc24a5a [0x7f98cfc24540+0x51a]
> J 34634 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(JJJLorg/apache/ignite/internal/processors/cache/persistence/tree/io/BPlusIO;Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Get;I)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
> (380 bytes) @ 0x7f98d32dd524 [0x7f98d32dd100+0x424]
> J 34633 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;Lorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageHandler;Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object;
> (81 bytes) @ 0x7f98d2091c94 [0x7f98d2091a40+0x254]
> J 34888 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
> (561 bytes) @ 0x7f98d2ca146c [0x7f98d2ca1180+0x2ec]
> J 34888 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
> (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
> (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 34888 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Invoke;JJJI)Lorg/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree$Result;
> (561 bytes) @ 0x7f98d2ca17f8 [0x7f98d2ca1180+0x678]
> J 35053 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/ignite/internal/util/Igni
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (IGNITE-6421) Ignite WAL reader: add shell script to start converter
[ https://issues.apache.org/jira/browse/IGNITE-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-6421. Resolution: Won't Fix No interest in this tool, so saving the idea as won't fix > Ignite WAL reader: add shell script to start converter > -- > > Key: IGNITE-6421 > URL: https://issues.apache.org/jira/browse/IGNITE-6421 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > Support simple startup for utility > https://cwiki.apache.org/confluence/display/IGNITE/Ignite+WAL+reader by > providing shell and bat files > Options which can be defined by command line > - Option A: Manual setup of directory paths. > -- Page size (int) > -- Path to WAL work directory (string) > -- Path to WAL archive directory > -- Path to marshaller cache > -- Path to binary metadata > -- Option to keep binary objects binary > -- additional classpath for business classes (optional) > - Option B: Standard Ignite folders structure > -- Page size (int) > -- Path to Ignite work directory (string) > -- Consistent ID (string) > -- Option to keep binary objects binary > -- additional classpath for business classes (optional) > Because of huge number of options it may be preferable to provide > config(property) file. This file may be used to setup all options except > classpath. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-10259) Javadoc online links are not visible
[ https://issues.apache.org/jira/browse/IGNITE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10259. - Resolution: Fixed > Javadoc online links are not visible > > > Key: IGNITE-10259 > URL: https://issues.apache.org/jira/browse/IGNITE-10259 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Cameron Steffen >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.7.5 > > Attachments: image-2018-11-14-11-50-24-269.png > > > Some of the links on the top of the javadoc pages online are not visible > until I hover the mouse over them. Seems to be caused by some images failing > to download with 404. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-10259) Javadoc online links are not visible
[ https://issues.apache.org/jira/browse/IGNITE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10259: Fix Version/s: 2.7.5 > Javadoc online links are not visible > > > Key: IGNITE-10259 > URL: https://issues.apache.org/jira/browse/IGNITE-10259 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Cameron Steffen >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.7.5 > > Attachments: image-2018-11-14-11-50-24-269.png > > > Some of the links on the top of the javadoc pages online are not visible > until I hover the mouse over them. Seems to be caused by some images failing > to download with 404. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-11932) Follow ASF crypto process, declare encryption software usages
[ https://issues.apache.org/jira/browse/IGNITE-11932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11932: Fix Version/s: 2.8 > Follow ASF crypto process, declare encryption software usages > - > > Key: IGNITE-11932 > URL: https://issues.apache.org/jira/browse/IGNITE-11932 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > https://www.apache.org/dev/crypto.html > We need to update > https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml > And inform users by including crypto notice -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-11932) Follow ASF crypto process, declare encryption software usages
[ https://issues.apache.org/jira/browse/IGNITE-11932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-11932. - Resolution: Fixed > Follow ASF crypto process, declare encryption software usages > - > > Key: IGNITE-11932 > URL: https://issues.apache.org/jira/browse/IGNITE-11932 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > https://www.apache.org/dev/crypto.html > We need to update > https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml > And inform users by including crypto notice -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12006) Threads may be parked for indefinite time during throttling after spurious wakeups
[
https://issues.apache.org/jira/browse/IGNITE-12006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892902#comment-16892902
]
Vladislav Pyatkov commented on IGNITE-12006:
[~antonovsergey93] looks good.
But optionally I advice to put in constant instead of magic value 1/2 in method
{{releaseCheckpointBufferPage}}. Like it done for {{CP_BUF_FILL_THRESHOLD}}.
> Threads may be parked for indefinite time during throttling after spurious
> wakeups
> --
>
> Key: IGNITE-12006
> URL: https://issues.apache.org/jira/browse/IGNITE-12006
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the log we see the following behavior:
> {noformat}
> 2019-07-04 06:29:03.649[WARN
> ][sys-#328%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#328%NODE%xyzGridNodeName% for timeout(ms)=16335
> 2019-07-04 06:29:03.649[WARN
> ][sys-#326%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#326%NODE%xyzGridNodeName% for timeout(ms)=13438
> 2019-07-04 06:29:03.649[WARN
> ][sys-#277%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#277%NODE%xyzGridNodeName% for timeout(ms)=11609
> 2019-07-04 06:29:03.649[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=18009
> 2019-07-04 06:29:03.649[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=15557
> 2019-07-04 06:29:03.650[WARN
> ][sys-#307%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#307%NODE%xyzGridNodeName% for timeout(ms)=27938
> 2019-07-04 06:29:03.649[WARN
> ][sys-#316%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#316%NODE%xyzGridNodeName% for timeout(ms)=12189
> 2019-07-04 06:29:03.649[WARN
> ][sys-#311%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#311%NODE%xyzGridNodeName% for timeout(ms)=11056
> 2019-07-04 06:29:03.650[WARN
> ][sys-#295%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#295%NODE%xyzGridNodeName% for timeout(ms)=20848
> 2019-07-04 06:29:03.649[WARN
> ][sys-#290%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#290%NODE%xyzGridNodeName% for timeout(ms)=14816
> 2019-07-04 06:29:03.649[WARN
> ][sys-#332%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#332%NODE%xyzGridNodeName% for timeout(ms)=14110
> 2019-07-04 06:29:03.649[WARN
> ][sys-#298%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#298%NODE%xyzGridNodeName% for timeout(ms)=10028
> 2019-07-04 06:29:03.650[WARN
> ][sys-#304%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#304%NODE%xyzGridNodeName% for timeout(ms)=19855
> 2019-07-04 06:29:03.650[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=41277
> 2019-07-04 06:29:03.650[WARN
> ][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=17151
> 2019-07-04 06:29:03.650[WARN
> ][sys-#308%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#308%NODE%xyzGridNodeName% for timeout(ms)=39312
> 2019-07-04 06:29:03.650[WARN
> ][sys-#322%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#322%NODE%xyzGridNodeName% for timeout(ms)=43341
> 2019-07-04 06:29:03.650[WARN
> ][sys-#306%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#306%NODE%xyzGridNodeName% for timeout(ms)=21890
> 2019-07-04 06:29:03.650[WARN
> ][sys-#315%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#315%NODE%xyzGridNodeName% for timeout(ms)=18909
> 2019-07-04 06:29:03.650[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=74129
> 2019-07-04 06:29:03.650[WARN
> ][sys-#305%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#305%NODE%xyzGridNodeName% for timeout(ms)=26608
> 2019-07-04 06:29:03.650[WARN
> ][sys-#309%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#309%NODE%xyzGridNodeName% for timeout(ms)=77835
> 2019-07-04 06:29:03.650[WARN
> ][sys-#291%NODE%xyzGrid
[jira] [Commented] (IGNITE-11979) Add ability to set default parallelizm of rebuild indexes in configuration
[
https://issues.apache.org/jira/browse/IGNITE-11979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892901#comment-16892901
]
Denis Chudov commented on IGNITE-11979:
---
[~amashenkov], I've done fixes and left comment. Please take a look once again.
> Add ability to set default parallelizm of rebuild indexes in configuration
> --
>
> Key: IGNITE-11979
> URL: https://issues.apache.org/jira/browse/IGNITE-11979
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We can't change SchemaIndexCacheVisitorImpl#DFLT_PARALLELISM at the moment:
> {code:java}
> /** Default degree of parallelism. */
> private static final int DFLT_PARALLELISM = Math.min(4, Math.max(1,
> Runtime.getRuntime().availableProcessors() / 4));
> {code}
> On huge servers with a lot of cores (such as 56) we will rebuild indexes in 4
> threads. I think we should have ability to set DFLT_PARALLELISM in Ignite
> configuration.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (IGNITE-11373) varchar_ignorecase doesn't work properly
[
https://issues.apache.org/jira/browse/IGNITE-11373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev resolved IGNITE-11373.
Resolution: Duplicate
> varchar_ignorecase doesn't work properly
>
>
> Key: IGNITE-11373
> URL: https://issues.apache.org/jira/browse/IGNITE-11373
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Looks like a field with type varchar_ignorecase can't be used for filtering
> the values for different cases.
> {code:java}
> Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
>
> IgniteCache cache = ignite.getOrCreateCache("TEST");
> cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
> "(\n" +
> " TEST_IDNUMBER(15)NOT NULL,\n" +
> " TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
> " PRIMARY KEY (TEST_ID)\n" +
> ") "));
> System.out.println("INSERTED:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());
> System.out.println("FOUND:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("Select * from TEST where TEST_VALUE like
> '%aaa%'")).getAll().size());
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11997: -- Ignite Flags: (was: Docs Required) > TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1 > > > Key: IGNITE-11997 > URL: https://issues.apache.org/jira/browse/IGNITE-11997 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: tests > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IgniteCacheQueriesLoadTest1.testQueries have long execution. Need to > investigate the reasons and fix it if possible. > org.apache.ignite.testsuites.IgniteBinaryCacheQueryTestSuite2: > org.apache.ignite.internal.processors.cache.IgniteCacheQueriesLoadTest1.testQueries > 2m 52.81s -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892773#comment-16892773 ] Pavel Kuznetsov commented on IGNITE-11997: -- [~amashenkov] would you please take a look at the patch? > TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1 > > > Key: IGNITE-11997 > URL: https://issues.apache.org/jira/browse/IGNITE-11997 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: tests > Time Spent: 10m > Remaining Estimate: 0h > > IgniteCacheQueriesLoadTest1.testQueries have long execution. Need to > investigate the reasons and fix it if possible. > org.apache.ignite.testsuites.IgniteBinaryCacheQueryTestSuite2: > org.apache.ignite.internal.processors.cache.IgniteCacheQueriesLoadTest1.testQueries > 2m 52.81s -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12017) Avoid calling GridDhtPartitionsExchangeFuture#onEvent more than once.
[
https://issues.apache.org/jira/browse/IGNITE-12017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-12017:
-
Description:
When the GridDhtPartitionsExchangeFuture#onEvent method called it releases
event latch. It means that we can't change the initial event (firstDiscoEvt).
Otherwise, it breaks the exchange logic.
I have checked on TC and this method may be called twice with one event
(identical references).
The following assert is correct:
{noformat}
assert exchId.equals(this.exchId) && (firstDiscoEvt == null || firstDiscoEvt ==
discoEvt);
{noformat}
Need to refactor the method usages and avoid confusing developers that the
first event may be changed.
was:
When the GridDhtPartitionsExchangeFuture#onEvent method called it releases init
latch. It means that we can't change the initial event (firstDiscoEvt).
Otherwise, it breaks the exchange logic.
I have checked on TC and this method may be called twice with one event
(identical references).
The following assert is correct:
{noformat}
assert exchId.equals(this.exchId) && (firstDiscoEvt == null || firstDiscoEvt ==
discoEvt);
{noformat}
Need to refactor the method usages and avoid confusing developers that the
first event may be changed.
> Avoid calling GridDhtPartitionsExchangeFuture#onEvent more than once.
> -
>
> Key: IGNITE-12017
> URL: https://issues.apache.org/jira/browse/IGNITE-12017
> Project: Ignite
> Issue Type: Task
>Reporter: Amelchev Nikita
>Priority: Major
>
> When the GridDhtPartitionsExchangeFuture#onEvent method called it releases
> event latch. It means that we can't change the initial event (firstDiscoEvt).
> Otherwise, it breaks the exchange logic.
> I have checked on TC and this method may be called twice with one event
> (identical references).
> The following assert is correct:
> {noformat}
> assert exchId.equals(this.exchId) && (firstDiscoEvt == null || firstDiscoEvt
> == discoEvt);
> {noformat}
> Need to refactor the method usages and avoid confusing developers that the
> first event may be changed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12017) Avoid calling GridDhtPartitionsExchangeFuture#onEvent more than once.
Amelchev Nikita created IGNITE-12017:
Summary: Avoid calling GridDhtPartitionsExchangeFuture#onEvent
more than once.
Key: IGNITE-12017
URL: https://issues.apache.org/jira/browse/IGNITE-12017
Project: Ignite
Issue Type: Task
Reporter: Amelchev Nikita
When the GridDhtPartitionsExchangeFuture#onEvent method called it releases init
latch. It means that we can't change the initial event (firstDiscoEvt).
Otherwise, it breaks the exchange logic.
I have checked on TC and this method may be called twice with one event
(identical references).
The following assert is correct:
{noformat}
assert exchId.equals(this.exchId) && (firstDiscoEvt == null || firstDiscoEvt ==
discoEvt);
{noformat}
Need to refactor the method usages and avoid confusing developers that the
first event may be changed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892695#comment-16892695
]
Ignite TC Bot commented on IGNITE-7883:
---
{panel:title=Branch: [pull/5932/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4394009]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4394092&buildTypeId=IgniteTests24Java8_RunAll]
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12016) Is there option to increase or decrease Ignite SQL Table backup count after its initialized?
hirik created IGNITE-12016: -- Summary: Is there option to increase or decrease Ignite SQL Table backup count after its initialized? Key: IGNITE-12016 URL: https://issues.apache.org/jira/browse/IGNITE-12016 Project: Ignite Issue Type: New Feature Reporter: hirik Hi, We are working in a dynamic environment, based on the new nodes we should update the backup count of existing SQL tables. is there any api available to support this requirement? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-12015) Text caseinsensitive search
[ https://issues.apache.org/jira/browse/IGNITE-12015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hirik resolved IGNITE-12015. Resolution: Duplicate > Text caseinsensitive search > > > Key: IGNITE-12015 > URL: https://issues.apache.org/jira/browse/IGNITE-12015 > Project: Ignite > Issue Type: Improvement >Reporter: hirik >Priority: Critical > > Hi, > I'm looking for > [VARCHAR_IGNORECASE|http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type] > kind of datatype in Ignite SQL for text ignore-case search. Is there any > reason for this not available in Ignite even though Apache Ignite SQL engine > is tightly coupled with H2 database? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-11373) varchar_ignorecase doesn't work properly
[
https://issues.apache.org/jira/browse/IGNITE-11373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892677#comment-16892677
]
Ivan Pavlukhin commented on IGNITE-11373:
-
[~ezhuravl], could we resolve this ticket as a duplicate of IGNITE-3999?
> varchar_ignorecase doesn't work properly
>
>
> Key: IGNITE-11373
> URL: https://issues.apache.org/jira/browse/IGNITE-11373
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> Looks like a field with type varchar_ignorecase can't be used for filtering
> the values for different cases.
> {code:java}
> Ignite ignite = Ignition.start("examples/config/example-ignite.xml");
>
> IgniteCache cache = ignite.getOrCreateCache("TEST");
> cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
> "(\n" +
> " TEST_IDNUMBER(15)NOT NULL,\n" +
> " TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
> " PRIMARY KEY (TEST_ID)\n" +
> ") "));
> System.out.println("INSERTED:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());
> System.out.println("FOUND:" + ignite.cache("TEST").query(new
> SqlFieldsQuery("Select * from TEST where TEST_VALUE like
> '%aaa%'")).getAll().size());
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12015) Text caseinsensitive search
[
https://issues.apache.org/jira/browse/IGNITE-12015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892676#comment-16892676
]
Ivan Pavlukhin commented on IGNITE-12015:
-
[~hirik], {{VARCHAR_IGNORECASE}} is not supported in Ignite. Could we resolve
this ticket as a duplicate of IGNITE-3999?
> Text caseinsensitive search
>
>
> Key: IGNITE-12015
> URL: https://issues.apache.org/jira/browse/IGNITE-12015
> Project: Ignite
> Issue Type: Improvement
>Reporter: hirik
>Priority: Critical
>
> Hi,
> I'm looking for
> [VARCHAR_IGNORECASE|http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type]
> kind of datatype in Ignite SQL for text ignore-case search. Is there any
> reason for this not available in Ignite even though Apache Ignite SQL engine
> is tightly coupled with H2 database?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12015) Text caseinsensitive search
hirik created IGNITE-12015: -- Summary: Text caseinsensitive search Key: IGNITE-12015 URL: https://issues.apache.org/jira/browse/IGNITE-12015 Project: Ignite Issue Type: Improvement Reporter: hirik Hi, I'm looking for [VARCHAR_IGNORECASE|http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type] kind of datatype in Ignite SQL for text ignore-case search. Is there any reason for this not available in Ignite even though Apache Ignite SQL engine is tightly coupled with H2 database? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12014) Getting affinity for topology version earlier than affinity is calculated for system cache
PetrovMikhail created IGNITE-12014:
--
Summary: Getting affinity for topology version earlier than
affinity is calculated for system cache
Key: IGNITE-12014
URL: https://issues.apache.org/jira/browse/IGNITE-12014
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.5
Reporter: PetrovMikhail
Attachments: JcacheExchangeAwaitTest.java
The following exception was being caught occasionally on a big cluster (128
nodes) after it's activation and concurrent Ignite#reentrantLock() method call
from different nodes. (On 16 nodes cluster this exception was never detected
with no code change).
It's attached a presumptive reproducer of that problem which stable fails with
the specified exception.
{code:java}
java.lang.IllegalStateException: Getting affinity for topology version earlier
than affinity is calculated [locNode=TcpDiscoveryNode
[id=cf397493-7528-46dc-bc5a-444f9d51, consistentId=127.0.0.1:47501,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
discPort=47501, order=2, intOrder=2, lastExchangeTime=1564050248387, loc=true,
ver=2.8.0#20190725-sha1:, isClient=false],
grp=default-volatile-ds-group, topVer=AffinityTopologyVersion [topVer=2,
minorTopVer=1], lastAffChangeTopVer=AffinityTopologyVersion [topVer=2,
minorTopVer=1], head=AffinityTopologyVersion [topVer=2, minorTopVer=2],
history=[AffinityTopologyVersion [topVer=2, minorTopVer=2]]]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:802)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:749)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:657)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:227)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:273)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:264)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:288)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.entryExx(GridDhtColocatedCache.java:161)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.entryEx(GridNearTxLocal.java:4470)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.enlistRead(GridNearTxLocal.java:2709)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:2188)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:204)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5644)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4561)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:202)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4842)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.repairableGet(GridCacheAdapter.java:4808)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1480)
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:396)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$4.applyx(DataStructuresProcessor.java:561)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$4.applyx(DataStructuresProcessor.java:556)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1664)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.getAtomic(DataStructuresProcessor.java:556)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.reentrantLock(DataStructuresProcessor.java:1361)
at
org.apache.ignite.internal.IgniteKernal.reentrantLock(IgniteKernal.java:4065)
at
org.apache.ignite.JcacheExchangeAwaitTest.testJcacheExchangeAwait(JcacheExchangeAwaitTest.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[jira] [Created] (IGNITE-12013) NullPointerException is thrown by ExchangeLatchManager during cache creation
Vyacheslav Koptilin created IGNITE-12013:
Summary: NullPointerException is thrown by ExchangeLatchManager
during cache creation
Key: IGNITE-12013
URL: https://issues.apache.org/jira/browse/IGNITE-12013
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Attachments: ignitenullpointer.log
{{NullPointerException}} may be thrown during cluster topology change:
{code:java}
[14:15:49,820][SEVERE][exchange-worker-#63][GridDhtPartitionsExchangeFuture]
Failed to reinitialize local partitions (rebalancing will be stopped):
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=468,
minorTopVer=1], discoEvt=DiscoveryCustomEvent
[customMsg=DynamicCacheChangeBatch
[id=728f11e1c61-11d31f36-508d-47e0-9a9c-d4f5a270948d,
reqs=[DynamicCacheChangeRequest [cacheName=SQL_PUBLIC_UPRIYA_112093_TB,
hasCfg=true, nodeId=10a0b1a4-09bb-4aa6-81e0-537a6431283b,
clientStartOnly=false, stop=false, destroy=false, disabledAfterStartfalse]],
exchangeActions=ExchangeActions [startCaches=[SQL_PUBLIC_UPRIYA_112093_TB],
stopCaches=null, startGrps=[SQL_PUBLIC_UPRIYA_112093_TB], stopGrps=[],
resetParts=null, stateChangeRequest=null], startCaches=false],
affTopVer=AffinityTopologyVersion [topVer=468, minorTopVer=1],
super=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=10a0b1a4-09bb-4aa6-81e0-537a6431283b, addrs=[0:0:0:0:0:0:0:1%lo,
10.244.1.100, 127.0.0.1], sockAddrs=[/10.244.1.100:0, /0:0:0:0:0:0:0:1%lo:0,
/127.0.0.1:0], discPort=0, order=39, intOrder=27,
lastExchangeTime=1563872413854, loc=false, ver=2.7.0#20181130-sha1:256ae401,
isClient=true], topVer=468, nodeId8=6a076901, msg=null,
type=DISCOVERY_CUSTOM_EVT, tstamp=1563891349722]], nodeId=10a0b1a4,
evt=DISCOVERY_CUSTOM_EVT]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.canSkipJoiningNodes(ExchangeLatchManager.java:327)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1401)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:806)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:745)
{code}
The original topic on the user-list:
[http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-7-0-server-node-null-pointer-exception-td28899.html]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Reopened] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
[
https://issues.apache.org/jira/browse/IGNITE-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reopened IGNITE-12007:
-
Ok if web console build from sources is affected, I absolutely don't mind if
someone fixes it.
I wrongly considered is a binary-only issue.
I reopen the issue and left unassigned.
> Latest "apacheignite/web-console-backend" docker image is broken
>
>
> Key: IGNITE-12007
> URL: https://issues.apache.org/jira/browse/IGNITE-12007
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.7
>Reporter: Igor Belyakov
>Priority: Critical
>
> It's not possible to run docker container by using the latest version of
> "apacheignite/web-console-backend" image.
> Next error happens on the start:
> {code:java}
> npm ERR! A complete log of this run can be found in:
> npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
> npm ERR! path /opt/web-console/package.json
> npm ERR! code ENOENT
> npm ERR! errno -2
> npm ERR! syscall open
> npm ERR! enoent ENOENT: no such file or directory, open
> '/opt/web-console/package.json'
> npm ERR! enoent This is related to npm not being able to find a file.
> npm ERR! enoent{code}
> How to reproduce:
> Run container by using docker-compose as described here:
> [https://hub.docker.com/r/apacheignite/web-console-backend]
>
> Seems like it was broken by the next commit:
> [https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892556#comment-16892556 ] Ivan Pavlukhin commented on IGNITE-10973: - [~ivanan.fed], I suppose that we should fix .NET tests somehow. Apparently now we are ready to start massive migration to junit5. And so we should announce it to dev-list to discuss a strategy for the massive migration. > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12012) .NET: ICompute.WithExecutor
Pavel Tupitsyn created IGNITE-12012: --- Summary: .NET: ICompute.WithExecutor Key: IGNITE-12012 URL: https://issues.apache.org/jira/browse/IGNITE-12012 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Propagate the following APIs to .NET: * IgniteCompute.withExecutor * IgniteConfiguration.ExecutorConfiguration -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
[
https://issues.apache.org/jira/browse/IGNITE-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892505#comment-16892505
]
Ilya Murchenko commented on IGNITE-12007:
-
[~dpavlov] as I can see - Dockerfile for Web Console Backend image is broken in
Apache/Ignite repository. I think we should fix at least Dockerfile.
> Latest "apacheignite/web-console-backend" docker image is broken
>
>
> Key: IGNITE-12007
> URL: https://issues.apache.org/jira/browse/IGNITE-12007
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.7
>Reporter: Igor Belyakov
>Priority: Critical
>
> It's not possible to run docker container by using the latest version of
> "apacheignite/web-console-backend" image.
> Next error happens on the start:
> {code:java}
> npm ERR! A complete log of this run can be found in:
> npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
> npm ERR! path /opt/web-console/package.json
> npm ERR! code ENOENT
> npm ERR! errno -2
> npm ERR! syscall open
> npm ERR! enoent ENOENT: no such file or directory, open
> '/opt/web-console/package.json'
> npm ERR! enoent This is related to npm not being able to find a file.
> npm ERR! enoent{code}
> How to reproduce:
> Run container by using docker-compose as described here:
> [https://hub.docker.com/r/apacheignite/web-console-backend]
>
> Seems like it was broken by the next commit:
> [https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
