[jira] [Commented] (IGNITE-9027) Web console: "Tried to load angular more than once" in unit tests
[ https://issues.apache.org/jira/browse/IGNITE-9027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547333#comment-16547333 ] Ilya Borisov commented on IGNITE-9027: -- This is caused by several factors: 1. Importing angular in unit tests. This is already handled by karma config, so those imports are safe to remove. 2. Importing angular in the app code. The global angular import is done in vendors.js, so these should be safe to remove too. If angular imports are removed, TS will nag about UMD module import, but this can be fixed by declaring global angular namespace in app.d.ts like suggested [here|https://stackoverflow.com/q/47542928/333777]. > Web console: "Tried to load angular more than once" in unit tests > - > > Key: IGNITE-9027 > URL: https://issues.apache.org/jira/browse/IGNITE-9027 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Attachments: image-2018-07-18-10-30-55-424.png, > image-2018-07-18-10-31-13-453.png > > > When running unit tests, several such warnings happen in a row: > !image-2018-07-18-10-31-13-453.png! > Fix whatever causes the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9027) Web console: "Tried to load angular more than once" in unit tests
Ilya Borisov created IGNITE-9027: Summary: Web console: "Tried to load angular more than once" in unit tests Key: IGNITE-9027 URL: https://issues.apache.org/jira/browse/IGNITE-9027 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Attachments: image-2018-07-18-10-30-55-424.png, image-2018-07-18-10-31-13-453.png When running unit tests, several such warnings happen in a row: !image-2018-07-18-10-31-13-453.png! Fix whatever causes the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547327#comment-16547327 ] Ilya Borisov commented on IGNITE-8958: -- Apparently, sce 1.7 adds "unsafe:" protocol to "javascript:void 0" hrefs, which in turn trigger an unknown protocol behavior in xdg-open (or something). I'll see if I can remove the "unsafe prefix" or "js:void 0". > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4h > Remaining Estimate: 44h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547327#comment-16547327 ] Ilya Borisov edited comment on IGNITE-8958 at 7/18/18 3:20 AM: --- Apparently, sce 1.7 adds "unsafe:" protocol to "javascript:void 0" hrefs, which in turn triggers an unknown protocol behavior in xdg-open (or something very similar). I'll see if I can remove the "unsafe" prefix or "js:void 0". was (Author: klaster_1): Apparently, sce 1.7 adds "unsafe:" protocol to "javascript:void 0" hrefs, which in turn trigger an unknown protocol behavior in xdg-open (or something). I'll see if I can remove the "unsafe prefix" or "js:void 0". > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4h > Remaining Estimate: 44h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-8958: -- Attachment: ignite-8958-1.png > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4h > Remaining Estimate: 44h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547321#comment-16547321 ] Vasiliy Sisko edited comment on IGNITE-8958 at 7/18/18 3:11 AM: # On switch of project version (on some other actions too) browser dialog *Open xdg-open* is shown. See ignite-8958-1 image. was (Author: vsisko): # On switch of project version (on some other actions too) browser dialog *Open xdg-open* is shown. > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4h > Remaining Estimate: 44h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547325#comment-16547325 ] Ilya Borisov commented on IGNITE-8958: -- [~vsisko] can you attach a screenshot? I'm not sure what a "browser dialog Open xdg-open" is. > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Original Estimate: 48h > Time Spent: 4h > Remaining Estimate: 44h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547321#comment-16547321 ] Vasiliy Sisko commented on IGNITE-8958: --- # On switch of project version (on some other actions too) browser dialog *Open xdg-open* is shown. > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Original Estimate: 48h > Time Spent: 4h > Remaining Estimate: 44h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[
https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547190#comment-16547190
]
ruchir choudhry edited comment on IGNITE-9023 at 7/17/18 11:22 PM:
---
Hello [~ivandasch]
It will only happen if the Debug is on, which is the correct, right,
Do you want we need to record it in the logs file and send to the client also ?
Will appreciate a quick reply, i will be able to pick this one.
private void processResourceRequest(UUID nodeId, GridDeploymentRequest req) {
if (log.isDebugEnabled())
log.debug("Received peer class/resource loading request [node=" + nodeId + ",
req=" + req + ']');
// this the place you want me to change ? its happening only is log.Debug is
true. which is the right thing to do , Pls confirm
if (req.responseTopic() == null) {
try
{ req.responseTopic(U.unmarshal(marsh, req.responseTopicBytes(),
U.resolveClassLoader(ctx.config(; }
catch (IgniteCheckedException e)
{ U.error(log, "Failed to process deployment request (will ignore): " + req,
e); return; }
}
--
Regards, Ruchir
was (Author: ruchirc):
Hello [~ivandasch]
It will only happen if the Debug is on, which is the correct, right,
Do you want we need to record it in the logs file and send to the client also ?
Will appreciate a quick reply, i will be able to pick this one.
private void processResourceRequest(UUID nodeId, GridDeploymentRequest req) {
if (log.isDebugEnabled())
log.debug("Received peer class/resource loading request [node=" + nodeId + ",
req=" + req + ']');
// this the place you want me to change ? its happening only is log.Debug is
true. which is the right thing to do , Pls confirm
if (req.responseTopic() == null) {
try {
req.responseTopic(U.unmarshal(marsh, req.responseTopicBytes(),
U.resolveClassLoader(ctx.config(;
}
catch (IgniteCheckedException e) {
U.error(log, "Failed to process deployment request (will ignore): " + req, e);
Regards,
Ruchir
return;
}
}
--
> LinkageError or ClassNotFoundException should not be swollen by
> GridDeploymentCommunication during processing deployment request.
> -
>
> Key: IGNITE-9023
> URL: https://issues.apache.org/jira/browse/IGNITE-9023
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: ruchir choudhry
>Priority: Minor
> Fix For: 2.7
>
>
> In current implementation any error, that is thrown in
> GridDeploymentCommunication#processResourceRequest, is ignored silently.
> Any error should be logged and send to client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[
https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547190#comment-16547190
]
ruchir choudhry edited comment on IGNITE-9023 at 7/17/18 11:10 PM:
---
Hello [~ivandasch]
It will only happen if the Debug is on, which is the correct, right,
Do you want we need to record it in the logs file and send to the client also ?
Will appreciate a quick reply, i will be able to pick this one.
private void processResourceRequest(UUID nodeId, GridDeploymentRequest req) {
if (log.isDebugEnabled())
log.debug("Received peer class/resource loading request [node=" + nodeId + ",
req=" + req + ']');
// this the place you want me to change ? its happening only is log.Debug is
true. which is the right thing to do , Pls confirm
if (req.responseTopic() == null) {
try {
req.responseTopic(U.unmarshal(marsh, req.responseTopicBytes(),
U.resolveClassLoader(ctx.config(;
}
catch (IgniteCheckedException e) {
U.error(log, "Failed to process deployment request (will ignore): " + req, e);
Regards,
Ruchir
return;
}
}
--
was (Author: ruchirc):
Hello [~ivandasch]
It will only happen if the Debug is on, which is the correct, right,
Do you want we need to record it in the logs file and send to the client also ?
Will appreciate a quick reply, i will be able to pick this one.
if (!busyLock.enterBusy())
{ if (log.isDebugEnabled()) log.debug("Ignoring deployment request since grid
is stopping " + "[nodeId=" + nodeId + ", msg=" + msg + ']'); return; }
--
> LinkageError or ClassNotFoundException should not be swollen by
> GridDeploymentCommunication during processing deployment request.
> -
>
> Key: IGNITE-9023
> URL: https://issues.apache.org/jira/browse/IGNITE-9023
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: ruchir choudhry
>Priority: Minor
> Fix For: 2.7
>
>
> In current implementation any error, that is thrown in
> GridDeploymentCommunication#processResourceRequest, is ignored silently.
> Any error should be logged and send to client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[
https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547190#comment-16547190
]
ruchir choudhry edited comment on IGNITE-9023 at 7/17/18 11:01 PM:
---
Hello [~ivandasch]
It will only happen if the Debug is on, which is the correct, right,
Do you want we need to record it in the logs file and send to the client also ?
Will appreciate a quick reply, i will be able to pick this one.
if (!busyLock.enterBusy())
{ if (log.isDebugEnabled()) log.debug("Ignoring deployment request since grid
is stopping " + "[nodeId=" + nodeId + ", msg=" + msg + ']'); return; }
--
was (Author: ruchirc):
Hello
It will only happen if the Debug is on, which is the correct, right,
Do you want we need to record it in the logs and send to the client also ?
Will appreciate a quick reply, i will be able to pick this one.
-
if (!busyLock.enterBusy()) {
if (log.isDebugEnabled())
log.debug("Ignoring deployment request since grid is stopping " + "[nodeId=" +
nodeId + ", msg=" + msg + ']');
return;
}
--
> LinkageError or ClassNotFoundException should not be swollen by
> GridDeploymentCommunication during processing deployment request.
> -
>
> Key: IGNITE-9023
> URL: https://issues.apache.org/jira/browse/IGNITE-9023
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: ruchir choudhry
>Priority: Minor
> Fix For: 2.7
>
>
> In current implementation any error, that is thrown in
> GridDeploymentCommunication#processResourceRequest, is ignored silently.
> Any error should be logged and send to client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[ https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ruchir choudhry reassigned IGNITE-9023: --- Assignee: ruchir choudhry > LinkageError or ClassNotFoundException should not be swollen by > GridDeploymentCommunication during processing deployment request. > - > > Key: IGNITE-9023 > URL: https://issues.apache.org/jira/browse/IGNITE-9023 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: ruchir choudhry >Priority: Minor > Fix For: 2.7 > > > In current implementation any error, that is thrown in > GridDeploymentCommunication#processResourceRequest, is ignored silently. > Any error should be logged and send to client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[
https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547190#comment-16547190
]
ruchir choudhry commented on IGNITE-9023:
-
Hello
It will only happen if the Debug is on, which is the correct, right,
Do you want we need to record it in the logs and send to the client also ?
Will appreciate a quick reply, i will be able to pick this one.
-
if (!busyLock.enterBusy()) {
if (log.isDebugEnabled())
log.debug("Ignoring deployment request since grid is stopping " + "[nodeId=" +
nodeId + ", msg=" + msg + ']');
return;
}
--
> LinkageError or ClassNotFoundException should not be swollen by
> GridDeploymentCommunication during processing deployment request.
> -
>
> Key: IGNITE-9023
> URL: https://issues.apache.org/jira/browse/IGNITE-9023
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.7
>
>
> In current implementation any error, that is thrown in
> GridDeploymentCommunication#processResourceRequest, is ignored silently.
> Any error should be logged and send to client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9026) Two levels of Peer class loading fails in CONTINUOUS mode
David Harvey created IGNITE-9026: Summary: Two levels of Peer class loading fails in CONTINUOUS mode Key: IGNITE-9026 URL: https://issues.apache.org/jira/browse/IGNITE-9026 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: David Harvey We had an seemingly functional system in SHARED_MODE, where we have a custom StreamReceiver that sometimes sends closures on the peer class loaded code to other servers. However, we ended up running out of Metaspace, because we had > 6000 class loaders! We suspected a regression in this change [https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c], so we switched to CONTINUOUS mode. We then started getting failures to load some of the classes for the closures on the second server. Through some testing and code inspection, there seems to be the following flaws between GridDeploymentCommunication.sendResourceRequest and its two callers. The callers iterate though all the participant nodes until they find an online node that responds to the request (timeout is treated as offline node), with either success or failure, and then the loop terminates. The assumption is that all nodes are equally capable of providing the resource, so if one fails, then the others would also fail. The first flaw is that GridDeploymentCommunication.sendResourceRequest() has a check for a cycle, i.e., whether the destination node is one of the nodes that originated or forwarded this request, and in that case, a failure response is faked. However, that causes the caller's loop to terminate. So depending on the order of the nodes in the participant list, sendResourceRequest() may fail before trying any nodes because it has one of the calling nodes on this list. It should instead be skipping any of the calling nodes. Example with 1 client node a 2 server nodes: C1 sends data to S1, which forwards closure to S2. C1 also sends to S2 which forwards to S1. So now the node lists on S1 and S2 contain C1 and the other S node. If the order of the node lists on S1 is (S2,C1) and on S2 (S1,C1), then when S1 tries to load a class, it will try S2, then S2 will try S1, but will get a fake failure generated, causing S2 not to try more nodes (i.e., C1), and causing S1 also not to try more nodes. The other flaw is the assumption that all participants have equal access to the resource. Assume S1 knows about userVersion1 via S3 and S4, with S3 though C1 and S4 through C2. If C2 fails, then S4 is not capable of getting back to a master, but S1 has no way of knowing that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7793) SQL does not work if value has index filed which name equals to affinity key name
[
https://issues.apache.org/jira/browse/IGNITE-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547159#comment-16547159
]
ruchir choudhry commented on IGNITE-7793:
-
[~michal.warecki] Can i take this one.
> SQL does not work if value has index filed which name equals to affinity key
> name
> -
>
> Key: IGNITE-7793
> URL: https://issues.apache.org/jira/browse/IGNITE-7793
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Priority: Blocker
> Fix For: 2.7
>
>
> SQL does not work if value has index filed which name equals to affinity key
> name:
> {code:java}
> public class AKey {
> @AffinityKeyMapped
> int a;
> public AKey(int a) {
> this.a = a;
> }
> }
> public class AVal {
> @QuerySqlField
> int a;
> public AVal(int a) {
> this.a = a;
> }
> }
> AKey aKey = new AKey(1);
> AVal aVal = new AVal(0);
> IgniteCache cache = ignite.cache("Instrument");
> cache.put(aKey, aVal);
> SqlFieldsQuery query = new SqlFieldsQuery("select * from \"Instrument\".AVal
> it where it.a=?");
> List> res = cache.query(query.setArgs(0)).getAll();
> if(res.isEmpty()) {
> System.out.println("! FAILED !!!");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9025) "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest
[ https://issues.apache.org/jira/browse/IGNITE-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546932#comment-16546932 ] Andrey Gura commented on IGNITE-9025: - [~EdShangGG] LGTM. Merged to master branch. Thanks for contribution! > "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest > -- > > Key: IGNITE-9025 > URL: https://issues.apache.org/jira/browse/IGNITE-9025 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > There are several problems. > 1. Some test fails because of concurrent issues. > 2. Each fail in producer-thread could cause configuration hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9025) "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest
[ https://issues.apache.org/jira/browse/IGNITE-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura updated IGNITE-9025: Fix Version/s: 2.7 > "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest > -- > > Key: IGNITE-9025 > URL: https://issues.apache.org/jira/browse/IGNITE-9025 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > There are several problems. > 1. Some test fails because of concurrent issues. > 2. Each fail in producer-thread could cause configuration hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9025) "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest
[ https://issues.apache.org/jira/browse/IGNITE-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev updated IGNITE-9025: -- Description: There are several problems. 1. Some test fails because of concurrent issues. 2. Each fail in producer-thread could cause configuration hanging. > "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest > -- > > Key: IGNITE-9025 > URL: https://issues.apache.org/jira/browse/IGNITE-9025 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Priority: Major > > There are several problems. > 1. Some test fails because of concurrent issues. > 2. Each fail in producer-thread could cause configuration hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9025) "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest
[ https://issues.apache.org/jira/browse/IGNITE-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546896#comment-16546896 ] ASF GitHub Bot commented on IGNITE-9025: GitHub user EdShangGG opened a pull request: https://github.com/apache/ignite/pull/4377 IGNITE-9025 "PDS 1" TC configuration could hang because of SegmentedR… …ingByteBufferTest Signed-off-by: EdShangGG You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9025 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4377.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 #4377 commit d91d59488b84fb210edf39d622e7405a79af5457 Author: EdShangGG Date: 2018-07-17T17:00:36Z IGNITE-9025 "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest Signed-off-by: EdShangGG > "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest > -- > > Key: IGNITE-9025 > URL: https://issues.apache.org/jira/browse/IGNITE-9025 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > There are several problems. > 1. Some test fails because of concurrent issues. > 2. Each fail in producer-thread could cause configuration hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9025) "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest
[ https://issues.apache.org/jira/browse/IGNITE-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-9025: - Assignee: Eduard Shangareev > "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest > -- > > Key: IGNITE-9025 > URL: https://issues.apache.org/jira/browse/IGNITE-9025 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > There are several problems. > 1. Some test fails because of concurrent issues. > 2. Each fail in producer-thread could cause configuration hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9024) Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546894#comment-16546894 ] ASF GitHub Bot commented on IGNITE-9024: GitHub user x-kreator opened a pull request: https://github.com/apache/ignite/pull/4376 IGNITE-9024 Wrong usage of idxLatch in DynamicIndexAbstractConcurrent… …SelfTest You can merge this pull request into a Git repository by running: $ git pull https://github.com/x-kreator/ignite ignite-9024 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4376.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 #4376 commit 9aab8df70838c921939bdbc5618f277c8664e7bd Author: Dmitriy Sorokin Date: 2018-07-17T16:53:39Z IGNITE-9024 Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest > Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest > - > > Key: IGNITE-9024 > URL: https://issues.apache.org/jira/browse/IGNITE-9024 > Project: Ignite > Issue Type: Test >Affects Versions: 2.5 >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > DynamicIndexAbstractConcurrentSelfTest has BlockingIndexing inplementation > which allows synchronize indexing operations with other concurrent routines. > Transition to waiting for unblock indexing state being notified from > awaitIndexing method by countDown() call on idxLatch, which should be > awaiting on test thread, but calls of countDown() method on idxLatch > instances are present in that code points too. > Replace of countDown() calls by await() calls on idxLatch instances is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9025) "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest
Eduard Shangareev created IGNITE-9025: - Summary: "PDS 1" TC configuration could hang because of SegmentedRingByteBufferTest Key: IGNITE-9025 URL: https://issues.apache.org/jira/browse/IGNITE-9025 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9024) Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-9024: Summary: Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest (was: Wrong usage of IdxLatch in DynamicIndexAbstractConcurrentSelfTest) > Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest > - > > Key: IGNITE-9024 > URL: https://issues.apache.org/jira/browse/IGNITE-9024 > Project: Ignite > Issue Type: Test >Affects Versions: 2.5 >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > DynamicIndexAbstractConcurrentSelfTest has BlockingIndexing inplementation > which allows synchronize indexing operations with other concurrent routines. > Transition to waiting for unblock indexing state being notified from > awaitIndexing method by countDown() call on idxLatch, which should be > awaiting on test thread, but calls of countDown() method on idxLatch > instances are present in that code points too. > Replace of countDown() calls by await() calls on idxLatch instances is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9024) Wrong usage of IdxLatch in DynamicIndexAbstractConcurrentSelfTest
Dmitriy Sorokin created IGNITE-9024: --- Summary: Wrong usage of IdxLatch in DynamicIndexAbstractConcurrentSelfTest Key: IGNITE-9024 URL: https://issues.apache.org/jira/browse/IGNITE-9024 Project: Ignite Issue Type: Test Affects Versions: 2.5 Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin Fix For: 2.7 DynamicIndexAbstractConcurrentSelfTest has BlockingIndexing inplementation which allows synchronize indexing operations with other concurrent routines. Transition to waiting for unblock indexing state being notified from awaitIndexing method by countDown() call on idxLatch, which should be awaiting on test thread, but calls of countDown() method on idxLatch instances are present in that code points too. Replace of countDown() calls by await() calls on idxLatch instances is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8761) WAL fsync at rollover should be asynchronous in LOG_ONLY and BACKGROUND modes
[
https://issues.apache.org/jira/browse/IGNITE-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546821#comment-16546821
]
Ivan Rakov commented on IGNITE-8761:
[~v.pyatkov], I've looked through your changes. A few comments:
1) Seems like WalSegmentSyncer mimics behavior of
FileWriteAheadLogManager#flush. Can we just call external flush from fsyncer
thread?
2) Current implementation stops WalSegmentSyncer through interruption. Please
look at shutdown mechanism of other WAL threads.
3) Potential StorageException during fsync is not handled
4) Why we need to use ConcurrentLinkedHashMap here? I don't see how it's
related to the original issue.
> WAL fsync at rollover should be asynchronous in LOG_ONLY and BACKGROUND modes
> -
>
> Key: IGNITE-8761
> URL: https://issues.apache.org/jira/browse/IGNITE-8761
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Ivan Rakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.7
>
>
> Transactions may periodically hang for a few seconds in LOG_ONLY or
> BACKGROUND persistent modes. Thread dumps show that threads are hanging on
> syncing previous WAL segment during rollover:
> {noformat}
> java.lang.Thread.State: RUNNABLE
>at java.nio.MappedByteBuffer.force0(MappedByteBuffer.java:-1)
>at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:203)
>at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.close(FileWriteAheadLogManager.java:2843)
>at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$600(FileWriteAheadLogManager.java:2483)
>at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.rollOver(FileWriteAheadLogManager.java:1094)
> {noformat}
> Waiting for this fsync is not necessary action to ensure crash recovery
> guarantees. Instead of this, we should just perform fsyncs asychronously and
> ensure that they are completed prior to next checkpoint start.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[ https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-9023: - Issue Type: Improvement (was: Bug) > LinkageError or ClassNotFoundException should not be swollen by > GridDeploymentCommunication during processing deployment request. > - > > Key: IGNITE-9023 > URL: https://issues.apache.org/jira/browse/IGNITE-9023 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Priority: Minor > Fix For: 2.7 > > > In current implementation any error, that is thrown in > GridDeploymentCommunication#processResourceRequest, is ignored silently. > Any error should be logged and send to client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
Ivan Daschinskiy created IGNITE-9023: Summary: LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request. Key: IGNITE-9023 URL: https://issues.apache.org/jira/browse/IGNITE-9023 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Ivan Daschinskiy Fix For: 2.7 In current implementation any error, that is thrown in GridDeploymentCommunication#processResourceRequest, is ignored silently. Any error should be logged and send to client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8759) TcpDiscoverySpi: detailed info about current state in MBean
[ https://issues.apache.org/jira/browse/IGNITE-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-8759: Fix Version/s: 2.7 > TcpDiscoverySpi: detailed info about current state in MBean > --- > > Key: IGNITE-8759 > URL: https://issues.apache.org/jira/browse/IGNITE-8759 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.7 > > > When TcpDiscoverySpi is used all nodes keep information about current > topology locally. Discovery protocol is responsible of keeping this > information consistent across all nodes. > However in situations of network glitches some nodes may have different > pictures of current state and topology of the cluster. > To make it easier to monitor state of the whole cluster and identify such > nodes quicker the following information should be presented via MBean > interface on each node: > * Current topology version; > * Hash of current topology (e.g. sum of hash codes of all nodeIds) (to allow > quick matching); > * Pretty-formatted snapshot of current topology visible from the node; > * Information about nodes visible/invisible to local one; > * Other information useful to monitoring of topology state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8759) TcpDiscoverySpi: detailed info about current state in MBean
[ https://issues.apache.org/jira/browse/IGNITE-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8759: --- Assignee: Dmitry Karachentsev > TcpDiscoverySpi: detailed info about current state in MBean > --- > > Key: IGNITE-8759 > URL: https://issues.apache.org/jira/browse/IGNITE-8759 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > > When TcpDiscoverySpi is used all nodes keep information about current > topology locally. Discovery protocol is responsible of keeping this > information consistent across all nodes. > However in situations of network glitches some nodes may have different > pictures of current state and topology of the cluster. > To make it easier to monitor state of the whole cluster and identify such > nodes quicker the following information should be presented via MBean > interface on each node: > * Current topology version; > * Hash of current topology (e.g. sum of hash codes of all nodeIds) (to allow > quick matching); > * Pretty-formatted snapshot of current topology visible from the node; > * Information about nodes visible/invisible to local one; > * Other information useful to monitoring of topology state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9013:
-
Fix Version/s: 2.7
> Node stop hangs if there was cache activities in Service Processor
> --
>
> Key: IGNITE-9013
> URL: https://issues.apache.org/jira/browse/IGNITE-9013
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> I have found this issue while running
> IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
> Also it affects IgniteServiceDynamicCachesSelfTest and Basic 1 TC
> configuration.
> And test hanged with:
> {code}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
> at
> org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> - locked <0x273d> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> {code}
> "srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
> tid=0x3d9 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove0(GridCacheAdapter.java:2948)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove(GridCacheAdapter.java:2932)
> at
>
[jira] [Assigned] (IGNITE-8760) TcpDiscoverySpi: validation of discovery message path on each node
[ https://issues.apache.org/jira/browse/IGNITE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8760: --- Assignee: Dmitry Karachentsev > TcpDiscoverySpi: validation of discovery message path on each node > -- > > Key: IGNITE-8760 > URL: https://issues.apache.org/jira/browse/IGNITE-8760 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > > As each discovery message goes across the ring it can record all nodes it was > handled on. > It gives discovery protocol an opportunity to set up a constant monitoring of > cluster topology: each node on receiving discovery message will compare path > recorded by the message and its local picture of current topology. On > detecting any discrepancy node may at least print warning or take other > actions. > Path recording may be expensive in terms of network traffic so it is better > to add this logic to specific types of discovery messages: all topology > changing messages and (may be) heartbeats. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546716#comment-16546716
]
ASF GitHub Bot commented on IGNITE-9005:
GitHub user slukyano opened a pull request:
https://github.com/apache/ignite/pull/4374
IGNITE-9005: Fixed initialization order.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9005
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4374.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 #4374
commit a8b591a5a9b39ba86a79e8a10aaaba6dc1cba69f
Author: Stanislav Lukyanov
Date: 2018-07-17T14:12:26Z
IGNITE-9005: Fixed initialization order.
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7246907407546697403=%3Cdefault%3E=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS
[ https://issues.apache.org/jira/browse/IGNITE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546714#comment-16546714 ] Sergey Chugunov commented on IGNITE-5569: - [~dkarachentsev], Improvement looks good to me, lets wait for TC status, and proceed with merging if it's OK. > TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a > cluster DDoS > - > > Key: IGNITE-5569 > URL: https://issues.apache.org/jira/browse/IGNITE-5569 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > A firewall configuration issue may effectively lead to a cluster DDoS. The > scheme is as follows: > 1) A node G joins the cluster, and a firewall rule forbids incoming > connection from cluster to this node > 2) Cluster successfully processes NodeAddedMesage and fires a discovery > NODE_JOINED event (not sure why?) > 4) The last node in the ring fails to connect to the newly joined node and > generates NODE_FAILED event > 5) Coordinator drops the connection, joining node attempts to connect again > The issues I see here: > 1) Neither coordinator nor joining node print out the reason why the joining > node failed / did not join. A slight hint (failed to send message to the next > node) is printed on the node with the largest order (the one that attempted > to close the ring), but the root cause (connection refused) is also not > printed > 2) The joining node attempts to connect to the cluster with the same node ID. > This violates an invariant we heavily rely on that once a node ID leaves a > cluster, this ID never comes back again > 3) Each discovery event leads to a partition exchange which blocks all cache > operations for a time interval equal at least to the full ring latency time. > If several nodes are started on a malicious host, this may lead to almost > full cluster degradation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546705#comment-16546705
]
ASF GitHub Bot commented on IGNITE-9012:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4367
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947=buildResultsDiv=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> 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.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9012:
-
Fix Version/s: 2.7
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947=buildResultsDiv=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> 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.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546680#comment-16546680
]
ASF GitHub Bot commented on IGNITE-9004:
Github user akalash closed the pull request at:
https://github.com/apache/ignite/pull/4362
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Given:
> # Activated Node1-1 in grid1.
> # MetaStorage on node1-1 in OffHeap.
> # MetaStorage have not storage on disk yet.
> When:
> # Checkpoint on node1-1 is starting. Start checkpoint marker was written.
> # node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
> Then:
> # node2-1 found expected checkpoint marker("Found unexpected checkpoint
> marker") and initialize FilePageStore for metaStorage by empty page
> # node1-1 finished checkpoint and wrote MetaStorage on disk.
> # After stop grid1 and activate grid2 node2-1 was failed because try read
> more than one page.
>
[jira] [Created] (IGNITE-9022) [ML] Implement class labels mapping for SVM binary classifier
Alexey Platonov created IGNITE-9022:
---
Summary: [ML] Implement class labels mapping for SVM binary
classifier
Key: IGNITE-9022
URL: https://issues.apache.org/jira/browse/IGNITE-9022
Project: Ignite
Issue Type: Bug
Components: ml
Reporter: Alexey Platonov
Assignee: Aleksey Zinoviev
Fix For: 2.7
We need to automatically compute mapping from user's labels to \{-1;1} for SVM.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8522) Transaction incorrect state after cache closed
[
https://issues.apache.org/jira/browse/IGNITE-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-8522:
Assignee: (was: Alexey Kuznetsov)
> Transaction incorrect state after cache closed
> --
>
> Key: IGNITE-8522
> URL: https://issues.apache.org/jira/browse/IGNITE-8522
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> When we started transaction on client node and closed cache , transaction is
> rolled back.
> But tx state is still ACTIVE which causes unexpected exception when we try to
> commit it.
> The expected exception is TransactionRollbackException.
> Look at the following code:
> {code:java}
> public void testTxRollbackWhenCacheClosed() throws Exception {
> startGrid(0);// server node started
> client = true;
> IgniteEx clientNode = startGrid(1);
> IgniteCache cache = clientNode.createCache();// transactional cache
> is started
> IgniteTransactions transactions = clientNode.transactions();
> Transaction tx = transactions.txStart();
> cache.put(1, 1);
> multithreaded(cache::close, 1);
> tx.commit();// TransactionRollbackException expected, but NPE is
> thrown.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov reassigned IGNITE-9004:
-
Assignee: Eduard Shangareev (was: Anton Kalashnikov)
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Given:
> # Activated Node1-1 in grid1.
> # MetaStorage on node1-1 in OffHeap.
> # MetaStorage have not storage on disk yet.
> When:
> # Checkpoint on node1-1 is starting. Start checkpoint marker was written.
> # node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
> Then:
> # node2-1 found expected checkpoint marker("Found unexpected checkpoint
> marker") and initialize FilePageStore for metaStorage by empty page
> # node1-1 finished checkpoint and wrote MetaStorage on disk.
> # After stop grid1 and activate grid2 node2-1 was failed because try read
> more than one page.
> Possible solution:
> * We can skip initialization FilePageStore for
[jira] [Updated] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov updated IGNITE-9004:
--
Summary: Failed to reinitialize local partitions (was: Failed to move temp
file during segment creation)
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Given:
> # Activated Node1-1 in grid1.
> # MetaStorage on node1-1 in OffHeap.
> # MetaStorage have not storage on disk yet.
> When:
> # Checkpoint on node1-1 is starting. Start checkpoint marker was written.
> # node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
> Then:
> # node2-1 found expected checkpoint marker("Found unexpected checkpoint
> marker") and initialize FilePageStore for metaStorage by empty page
> # node1-1 finished checkpoint and wrote MetaStorage on disk.
> # After stop grid1 and activate grid2 node2-1 was failed because try read
> more than one page.
> Possible solution:
> * We
[jira] [Updated] (IGNITE-9004) Failed to move temp file during segment creation
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov updated IGNITE-9004:
--
Description:
Reproduced by Activate/Deactivate suit, almost any tests in
IgniteChangeGlobalStateTest class. for example
IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
{noformat}
Failed to reinitialize local partitions (preloading will be stopped):
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
minorTopVer=1], discoEvt=DiscoveryCustomEvent
[customMsg=ChangeGlobalStateMessage
[id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
forceChangeBaselineTopology=false, timestamp=1531832492029],
affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
super=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1,
172.25.4.132], sockAddrs=[/172.25.4.132:47504, /0:0:0:0:0:0:0:1%lo:47504,
/127.0.0.1:47504], discPort=47504, order=2, intOrder=2,
lastExchangeTime=1531832486546, loc=false, ver=2.7.0#19700101-sha1:,
isClient=false], topVer=6, nodeId8=9960f6b9, msg=null,
type=DISCOVERY_CUSTOM_EVT, tstamp=1531832492035]], nodeId=8dced5ba,
evt=DISCOVERY_CUSTOM_EVT]
java.lang.AssertionError: calculatedOffset=3072, allocated=2048, headerSize=1024
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
at
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
at
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Given:
# Activated Node1-1 in grid1.
# MetaStorage on node1-1 in OffHeap.
# MetaStorage have not storage on disk yet.
When:
# Checkpoint on node1-1 is starting. Start checkpoint marker was written.
# node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
Then:
# node2-1 found expected checkpoint marker("Found unexpected checkpoint
marker") and initialize FilePageStore for metaStorage by empty page
# node1-1 finished checkpoint and wrote MetaStorage on disk.
# After stop grid1 and activate grid2 node2-1 was failed because try read more
than one page.
Possible solution:
* We can skip initialization FilePageStore for MetaStorage by empty page during
the start
* We can take a lock for metaStorage that only one node can read or write one
MetaStorage in one moment.
* We can reinitialize FilePageStore from disk when we activate cluster.
was:
Reproduced by Activate/Deactivate suit, for example
IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
{noformat}
class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
[13:56:05]W: [org.apache.ignite:ignite-core]
[jira] [Commented] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546651#comment-16546651
]
ASF GitHub Bot commented on IGNITE-9018:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4373
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> At least one timeout was caused by next
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
>
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
>
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9018:
---
Labels: MakeTeamcityGreenAgain (was: )
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> At least one timeout was caused by next
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
>
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
>
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9018:
---
Fix Version/s: 2.7
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> At least one timeout was caused by next
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
>
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
>
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546643#comment-16546643
]
Dmitriy Pavlov commented on IGNITE-9018:
[~EdShangGG], thank you for sharing link. I see that failed tests are flaky. We
can make an exception and do not run RunAll. Let's keep an eye on TC.
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> At least one timeout was caused by next
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
>
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
>
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9021) [ML] Refactor vectors to dence/sparse
Yury Babak created IGNITE-9021: -- Summary: [ML] Refactor vectors to dence/sparse Key: IGNITE-9021 URL: https://issues.apache.org/jira/browse/IGNITE-9021 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Aleksey Zinoviev Fix For: 2.7 We want to remove all unused implementations of Vector interface. Same for matrices. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8975) Invalid initialization of compressed archived WAL segment when WAL compression is switched off.
[
https://issues.apache.org/jira/browse/IGNITE-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546642#comment-16546642
]
ASF GitHub Bot commented on IGNITE-8975:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4345
> Invalid initialization of compressed archived WAL segment when WAL
> compression is switched off.
> ---
>
> Key: IGNITE-8975
> URL: https://issues.apache.org/jira/browse/IGNITE-8975
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.7
>
>
> After restarting node with WAL compression disabled and when compressed wal
> archive
> presentd, current implementation of FileWriteAheadLogManager ignores
> presenting compressed wal segment and initalizes empty brand new one. This
> causes following error:
> {code:java}
> 2018-07-05 16:14:25.761
> [ERROR][exchange-worker-#153%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.c.CheckpointHistory]
> Failed to process checkpoint: CheckpointEntry
> [id=8dc4b1cc-dedd-4a57-8748-f5a7ecfd389d, timestamp=1530785506909,
> ptr=FileWALPointer [idx=4520, fileOff=860507725, len=691515]]
> org.apache.ignite.IgniteCheckedException: Failed to find checkpoint record at
> the given WAL pointer: FileWALPointer [idx=4520, fileOff=860507725,
> len=691515]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.initIfNeeded(CheckpointEntry.java:346)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.access$300(CheckpointEntry.java:231)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.initIfNeeded(CheckpointEntry.java:123)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.groupState(CheckpointEntry.java:105)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.isCheckpointApplicableForGroup(CheckpointHistory.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.searchAndReserveCheckpoints(CheckpointHistory.java:304)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.reserveHistoryForExchange(GridCacheDatabaseSharedManager.java:1614)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:724)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2477)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2357)
> 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
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8684) Partition state exchange during rebalance continues to keep sending state messages (single,full) in loop even if no changes in partition states
[ https://issues.apache.org/jira/browse/IGNITE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546634#comment-16546634 ] ASF GitHub Bot commented on IGNITE-8684: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4287 > Partition state exchange during rebalance continues to keep sending state > messages (single,full) in loop even if no changes in partition states > --- > > Key: IGNITE-8684 > URL: https://issues.apache.org/jira/browse/IGNITE-8684 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > This is due to invalid "changed" state computation in > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CachePartitionFullCountersMap, > java.util.Set, > org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546620#comment-16546620
]
Eduard Shangareev commented on IGNITE-9018:
---
https://ci.ignite.apache.org/viewLog.html?buildId=1507395=queuedBuildOverviewTab
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> At least one timeout was caused by next
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
>
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
>
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9004) Failed to move temp file during segment creation
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546618#comment-16546618
]
Dmitriy Pavlov commented on IGNITE-9004:
I've failed all tests in class IgniteChangeGlobalStateTest so suite can run now.
> Failed to move temp file during segment creation
>
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
> temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
> 7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1446)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:2269)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4500(FileWriteAheadLogManager.java:143)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManage
> r.java:1862)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1606)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [13:56:05]W: [org.apache.ignite:ignite-core] Caused by:
> java.nio.file.NoSuchFileException:
> /data/teamcity/work/c182b70f2dfa6507/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal.tmp
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.nio.file.Files.move(Files.java:1395)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1442)
> [13:56:05]W: [org.apache.ignite:ignite-core] ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546603#comment-16546603
]
Sergey Chugunov edited comment on IGNITE-8131 at 7/17/18 1:28 PM:
--
[~garus.d.g],
I finally got the whole picture around the issue.
As part of execution of *ZookeeperDiscoveryImpl#processNewEvents(byte[] data)*
client tries to save some data to ZooKeeper (step 0) in
*ZookeeperClient#setData(String path, byte[] data, int ver)* but fails because
of *KeeperException$SessionExpiredException*.
Program flow doesn't return to *processNewEvents* and goes to
*ZookeeperClient#onZookeeperError* where reconnect closure is scheduled and
exception is thrown.
But *processNewEvents* didn't finish some logic crucial for successful
reconnect: it hasn't initialized *rtState.evtsData* where topVer for reconnect
event is obtained from.
Proposed fix tries to close this race by postponing saving data to ZooKeeper at
step 0 so *rtState.evtsData* will be initialized to the moment when session
expiration is detected. To me it is risky because it looks like all acks from
client nodes will be postponed for a significant amount of time (one minute by
default).
As we need *rtState.evtsData* only to retrieve topVer from it on reconnect, why
not save topVer earlier, before going to code which could face session
expiration?
So I opened a [PR|https://github.com/apache/ignite/pull/4366] with a quick fix
for the problem, could you take a look at it, please, and share your opinion?
It may be not a perfect place to do such early initialization, but we could
change it - the question is more about approach in general.
was (Author: sergey-chugunov):
[~garus.d.g],
I finally got the whole picture around the issue.
As part of execution of *ZookeeperDiscoveryImpl#processNewEvents(byte[] data)*
client tries to save some data to ZooKeeper (step 0) in
*ZookeeperClient#setData(String path, byte[] data, int ver)* but fails because
of *KeeperException$SessionExpiredException*.
Program flow doesn't return to *processNewEvents* and goes to
*ZookeeperClient#onZookeeperError* where reconnect closure is scheduled and
exception is thrown.
But *processNewEvents* didn't finish some logic crucial for successful
reconnect: it hasn't initialized *rtState.evtsData* where topVer for reconnect
is obtained from.
Proposed fix tries to avoid this race by postponing saving data to ZooKeeper at
step 0 so *rtState.evtsData* will be initialized to the moment when session
expiration is detected. To me it is risky because it looks like all acks from
client nodes will be postponed for a significant amount of time (one minute by
default).
As we need *rtState.evtsData* only to retrieve topVer from it on reconnect, why
not save topVer earlier, before going to code which could face session
expiration?
So I opened a [PR|https://github.com/apache/ignite/pull/4366] with a quick fix
for the problem, could you take a look at it, please, and share your opinion?
It may be not a perfect place to do such early initialization, but we could
change it - the question is more about approach in general.
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: ZK_client_reconnect_failure.log,
> ZK_client_reconnect_success.log
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with
[jira] [Commented] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546603#comment-16546603
]
Sergey Chugunov commented on IGNITE-8131:
-
[~garus.d.g],
I finally got the whole picture around the issue.
As part of execution of *ZookeeperDiscoveryImpl#processNewEvents(byte[] data)*
client tries to save some data to ZooKeeper (step 0) in
*ZookeeperClient#setData(String path, byte[] data, int ver)* but fails because
of *KeeperException$SessionExpiredException*.
Program flow doesn't return to *processNewEvents* but goes to
*ZookeeperClient#onZookeeperError* where reconnect closure is scheduled and
exception is thrown.
But *processNewEvents* didn't finish some logic crucial for successful
reconnect: it hasn't initialized *rtState.evtsData* where topVer for reconnect
is obtained from.
Proposed fix tries to avoid this race by postponing saving data to ZooKeeper at
step 0 so *rtState.evtsData* will be initialized to the moment when session
expiration is detected. To me it is risky because it looks like all acks from
client nodes will be postponed for a significant amount of time (one minute by
default).
As we need *rtState.evtsData* only to retrieve topVer from it on reconnect, why
not save topVer earlier, before going to code which could face session
expiration?
So I opened a [PR|https://github.com/apache/ignite/pull/4366] with a quick fix
for the problem, could you take a look at it, please, and share your opinion?
It may be not a perfect place to do such early initialization, but we could
change it - the question is more about approach in general.
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: ZK_client_reconnect_failure.log,
> ZK_client_reconnect_success.log
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546603#comment-16546603
]
Sergey Chugunov edited comment on IGNITE-8131 at 7/17/18 1:27 PM:
--
[~garus.d.g],
I finally got the whole picture around the issue.
As part of execution of *ZookeeperDiscoveryImpl#processNewEvents(byte[] data)*
client tries to save some data to ZooKeeper (step 0) in
*ZookeeperClient#setData(String path, byte[] data, int ver)* but fails because
of *KeeperException$SessionExpiredException*.
Program flow doesn't return to *processNewEvents* and goes to
*ZookeeperClient#onZookeeperError* where reconnect closure is scheduled and
exception is thrown.
But *processNewEvents* didn't finish some logic crucial for successful
reconnect: it hasn't initialized *rtState.evtsData* where topVer for reconnect
is obtained from.
Proposed fix tries to avoid this race by postponing saving data to ZooKeeper at
step 0 so *rtState.evtsData* will be initialized to the moment when session
expiration is detected. To me it is risky because it looks like all acks from
client nodes will be postponed for a significant amount of time (one minute by
default).
As we need *rtState.evtsData* only to retrieve topVer from it on reconnect, why
not save topVer earlier, before going to code which could face session
expiration?
So I opened a [PR|https://github.com/apache/ignite/pull/4366] with a quick fix
for the problem, could you take a look at it, please, and share your opinion?
It may be not a perfect place to do such early initialization, but we could
change it - the question is more about approach in general.
was (Author: sergey-chugunov):
[~garus.d.g],
I finally got the whole picture around the issue.
As part of execution of *ZookeeperDiscoveryImpl#processNewEvents(byte[] data)*
client tries to save some data to ZooKeeper (step 0) in
*ZookeeperClient#setData(String path, byte[] data, int ver)* but fails because
of *KeeperException$SessionExpiredException*.
Program flow doesn't return to *processNewEvents* but goes to
*ZookeeperClient#onZookeeperError* where reconnect closure is scheduled and
exception is thrown.
But *processNewEvents* didn't finish some logic crucial for successful
reconnect: it hasn't initialized *rtState.evtsData* where topVer for reconnect
is obtained from.
Proposed fix tries to avoid this race by postponing saving data to ZooKeeper at
step 0 so *rtState.evtsData* will be initialized to the moment when session
expiration is detected. To me it is risky because it looks like all acks from
client nodes will be postponed for a significant amount of time (one minute by
default).
As we need *rtState.evtsData* only to retrieve topVer from it on reconnect, why
not save topVer earlier, before going to code which could face session
expiration?
So I opened a [PR|https://github.com/apache/ignite/pull/4366] with a quick fix
for the problem, could you take a look at it, please, and share your opinion?
It may be not a perfect place to do such early initialization, but we could
change it - the question is more about approach in general.
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: ZK_client_reconnect_failure.log,
> ZK_client_reconnect_success.log
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
[jira] [Updated] (IGNITE-9020) .NET: Creating CacheEntry events regardless of values.
[ https://issues.apache.org/jira/browse/IGNITE-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-9020: Labels: dot_net iep-21 (was: dot_net) > .NET: Creating CacheEntry events regardless of values. > -- > > Key: IGNITE-9020 > URL: https://issues.apache.org/jira/browse/IGNITE-9020 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Amelchev Nikita >Priority: Minor > Labels: dot_net, iep-21 > Fix For: 2.7 > > > At Java, cache entry events serialize in > _PlatformUtils.writeCacheEntryEvent()_ method. It writes only _key_, _val_, > and _oldVal_. *EventType doesn't write*. > At .Net _ContinuousQueryUtils.ReadEvent0()_ method create events after check > on exist _val_ and _oldVal_ fields. > TCK 1.1 says that _getValue()_ not _null_ for REMOVE/EXPIRED events if old > value required and it breaks logic. > The possible solution is to check event type in this methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546563#comment-16546563
]
Dmitriy Pavlov commented on IGNITE-9013:
Checked TC and run looks OK, no suspicious tests found. One test with fail rate
0.0 (
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4343946256280463741=pull%2F4369%2Fhead=testDetails_IgniteTests24Java8=__all_branches__
) seems to fail in other branches
> Node stop hangs if there was cache activities in Service Processor
> --
>
> Key: IGNITE-9013
> URL: https://issues.apache.org/jira/browse/IGNITE-9013
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> I have found this issue while running
> IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
> Also it affects IgniteServiceDynamicCachesSelfTest and Basic 1 TC
> configuration.
> And test hanged with:
> {code}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
> at
> org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> - locked <0x273d> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> {code}
> "srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
> tid=0x3d9 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
>
[jira] [Comment Edited] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546552#comment-16546552
]
Alexey Kuznetsov edited comment on IGNITE-8570 at 7/17/18 12:56 PM:
[~andrey-kuznetsov] Actually I implemented API as you described :
user can subscribe either to a certain LOG Level by calling
{code:java}
log.listenError();
log.listenDebug();
//etc.
{code}
Or you can subscribe to all logs :
{code:java}
log.listen();
{code}
was (Author: alexey kuznetsov):
[~andrey-kuznetsov] Actually API such as you describe :
user can subscribe either to a certain LOG Level by calling
{code:java}
log.listenError();
log.listenDebug();
//etc.
{code}
Or you can subscribe to all logs :
{code:java}
log.listen();
{code}
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546552#comment-16546552
]
Alexey Kuznetsov commented on IGNITE-8570:
--
[~andrey-kuznetsov] Actually API such as you describe :
user can subscribe either to a certain LOG Level by calling
{code:java}
log.listenError();
log.listenDebug();
//etc.
{code}
Or you can subscribe to all logs :
{code:java}
log.listen();
{code}
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9020) .NET: Creating CacheEntry events regardless of values.
[ https://issues.apache.org/jira/browse/IGNITE-9020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-9020: Fix Version/s: 2.7 > .NET: Creating CacheEntry events regardless of values. > -- > > Key: IGNITE-9020 > URL: https://issues.apache.org/jira/browse/IGNITE-9020 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Amelchev Nikita >Priority: Minor > Labels: dot_net > Fix For: 2.7 > > > At Java, cache entry events serialize in > _PlatformUtils.writeCacheEntryEvent()_ method. It writes only _key_, _val_, > and _oldVal_. *EventType doesn't write*. > At .Net _ContinuousQueryUtils.ReadEvent0()_ method create events after check > on exist _val_ and _oldVal_ fields. > TCK 1.1 says that _getValue()_ not _null_ for REMOVE/EXPIRED events if old > value required and it breaks logic. > The possible solution is to check event type in this methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
[
https://issues.apache.org/jira/browse/IGNITE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546540#comment-16546540
]
Alexey Goncharuk commented on IGNITE-8783:
--
[~avinogradov],
Currently your change never completes the client latch because {{coordinator}}
is a {{ClusterNode}}, but {{nodeIds}} is a {{Set}}. Can you please
clarify why you need to check for coordinator?
> Failover tests periodically cause hanging of the whole Data Structures suite
> on TC
> --
>
> Key: IGNITE-8783
> URL: https://issues.apache.org/jira/browse/IGNITE-8783
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Ivan Rakov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> History of suite runs:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
> Chance of suite hang is 18% in master (based on previous 50 runs).
> Hang is always caused by one of the following failover tests:
> {noformat}
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9020) .NET: Creating CacheEntry events regardless of values.
Amelchev Nikita created IGNITE-9020: --- Summary: .NET: Creating CacheEntry events regardless of values. Key: IGNITE-9020 URL: https://issues.apache.org/jira/browse/IGNITE-9020 Project: Ignite Issue Type: Task Components: platforms Reporter: Amelchev Nikita At Java, cache entry events serialize in _PlatformUtils.writeCacheEntryEvent()_ method. It writes only _key_, _val_, and _oldVal_. *EventType doesn't write*. At .Net _ContinuousQueryUtils.ReadEvent0()_ method create events after check on exist _val_ and _oldVal_ fields. TCK 1.1 says that _getValue()_ not _null_ for REMOVE/EXPIRED events if old value required and it breaks logic. The possible solution is to check event type in this methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
[
https://issues.apache.org/jira/browse/IGNITE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-8783:
-
Fix Version/s: 2.7
> Failover tests periodically cause hanging of the whole Data Structures suite
> on TC
> --
>
> Key: IGNITE-8783
> URL: https://issues.apache.org/jira/browse/IGNITE-8783
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Ivan Rakov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> History of suite runs:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
> Chance of suite hang is 18% in master (based on previous 50 runs).
> Hang is always caused by one of the following failover tests:
> {noformat}
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546523#comment-16546523
]
Eduard Shangareev edited comment on IGNITE-9013 at 7/17/18 12:34 PM:
-
TC - https://ci.ignite.apache.org/viewLog.html?buildId=1503796;
PR - https://github.com/apache/ignite/pull/4369
was (Author: edshanggg):
https://ci.ignite.apache.org/viewLog.html?buildId=1503796;
> Node stop hangs if there was cache activities in Service Processor
> --
>
> Key: IGNITE-9013
> URL: https://issues.apache.org/jira/browse/IGNITE-9013
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> I have found this issue while running
> IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
> Also it affects IgniteServiceDynamicCachesSelfTest and Basic 1 TC
> configuration.
> And test hanged with:
> {code}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
> at
> org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> - locked <0x273d> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> {code}
> "srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
> tid=0x3d9 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
> at
>
[jira] [Created] (IGNITE-9019) Ignite prints redundant warnings on node start
Evgenii Zhuravlev created IGNITE-9019: - Summary: Ignite prints redundant warnings on node start Key: IGNITE-9019 URL: https://issues.apache.org/jira/browse/IGNITE-9019 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev It's scary to see so many warnings when you start node with default configuration: [WARN ][main][TcpCommunicationSpi] Message queue limit is set to 0 which may lead to potential OOMEs when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to message queues growth on sender and receiver sides. [WARN ][main][NoopCheckpointSpi] Checkpoints are disabled (to enable configure any GridCheckpointSpi implementation) [WARN ][main][GridCollisionManager] Collision resolution is disabled (all jobs will be activated upon arrival). [WARN ][main][IgniteKernal] Peer class loading is enabled (disable it in production for performance and deployment consistency reasons) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546523#comment-16546523
]
Eduard Shangareev commented on IGNITE-9013:
---
https://ci.ignite.apache.org/viewLog.html?buildId=1503796;
> Node stop hangs if there was cache activities in Service Processor
> --
>
> Key: IGNITE-9013
> URL: https://issues.apache.org/jira/browse/IGNITE-9013
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> I have found this issue while running
> IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
> Also it affects IgniteServiceDynamicCachesSelfTest and Basic 1 TC
> configuration.
> And test hanged with:
> {code}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
> at
> org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> - locked <0x273d> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> {code}
> "srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
> tid=0x3d9 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove0(GridCacheAdapter.java:2948)
> at
>
[jira] [Updated] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9013:
--
Description:
I have found this issue while running
IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
Also it affects IgniteServiceDynamicCachesSelfTest and Basic 1 TC configuration.
And test hanged with:
{code}
"main@1" prio=5 tid=0x1 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at
java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
at
java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
at
org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
- locked <0x273d> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
at
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
at junit.framework.TestCase.runBare(TestCase.java:146)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{code}
{code}
"srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
tid=0x3d9 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove0(GridCacheAdapter.java:2948)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove(GridCacheAdapter.java:2932)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1897)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2076)
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)
{code}
was:
I have found this issue while running
IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
And test hanged with:
{code}
"main@1" prio=5 tid=0x1 nid=NA waiting
java.lang.Thread.State:
[jira] [Commented] (IGNITE-9002) CPP Thin: Crash when used with dynamic cache without configuration
[ https://issues.apache.org/jira/browse/IGNITE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546515#comment-16546515 ] ASF GitHub Bot commented on IGNITE-9002: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4361 > CPP Thin: Crash when used with dynamic cache without configuration > -- > > Key: IGNITE-9002 > URL: https://issues.apache.org/jira/browse/IGNITE-9002 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Crash happens because of the unhandled case when cache has zero partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546513#comment-16546513
]
Eduard Shangareev commented on IGNITE-9012:
---
https://ci.ignite.apache.org/viewLog.html?buildId=1503469;
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947=buildResultsDiv=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> 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.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546498#comment-16546498
]
Stanislav Lukyanov commented on IGNITE-9005:
[~kcheng.mvp], [~dpavlov] The issue isn't with the CacheOffheapEvictionManager,
it's with the initialization order.
It is required that injection of the context (such as @CacheNameResource) is
done *before* processing LifecycleAware interfaces, so that if a bean (e.g.
eviction policy) both has an injection annotation and is LifecycleAware then
its start() method is executed after all injections are completed.
This invariant was broken for eviction policies by the fix IGNITE-8776.
The fix now would be to make sure that LifecycleAware is always processed after
the injections. I have a patch, will create a PR shortly.
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: kcheng.mvp
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7246907407546697403=%3Cdefault%3E=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov reassigned IGNITE-9005:
--
Assignee: Stanislav Lukyanov (was: kcheng.mvp)
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7246907407546697403=%3Cdefault%3E=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9002) CPP Thin: Crash when used with dynamic cache without configuration
[ https://issues.apache.org/jira/browse/IGNITE-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546494#comment-16546494 ] Igor Seliverstov commented on IGNITE-9002: -- [~isapego], looks OK > CPP Thin: Crash when used with dynamic cache without configuration > -- > > Key: IGNITE-9002 > URL: https://issues.apache.org/jira/browse/IGNITE-9002 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Crash happens because of the unhandled case when cache has zero partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546450#comment-16546450
]
ASF GitHub Bot commented on IGNITE-9018:
GitHub user EdShangGG opened a pull request:
https://github.com/apache/ignite/pull/4373
IGNITE-9018 PDS1 TC configuration hangs periodically
Signed-off-by: EdShangGG
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9018
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4373.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 #4373
commit 299e8fad41699f40eaf69a1f1e714211e63ac766
Author: EdShangGG
Date: 2018-07-17T11:25:40Z
IGNITE-9018 PDS1 TC configuration hangs periodically
Signed-off-by: EdShangGG
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> At least one timeout was caused by next
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
>
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
>
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9018:
--
Description:
At least one timeout was caused by next
{code}
"main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
condition [0x7ff12694e000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
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)
{code}
was:
At least one timeout was caused by next
{code} "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
condition [0x7ff12694e000] java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method) at
org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658) at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
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
junit.framework.TestCase.runBare(TestCase.java:141) at
junit.framework.TestResult$1.protect(TestResult.java:122) at
junit.framework.TestResult.runProtected(TestResult.java:142) at
junit.framework.TestResult.run(TestResult.java:125) at
junit.framework.TestCase.run(TestCase.java:129) at
junit.framework.TestSuite.runTest(TestSuite.java:255) at
junit.framework.TestSuite.run(TestSuite.java:250) at
junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.frame
{code}
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> At least one timeout was caused by next
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
>
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
>
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9018) PDS1 TC configuration hangs periodically
[
https://issues.apache.org/jira/browse/IGNITE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-9018:
-
Assignee: Eduard Shangareev
> PDS1 TC configuration hangs periodically
>
>
> Key: IGNITE-9018
> URL: https://issues.apache.org/jira/browse/IGNITE-9018
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> At least one timeout was caused by next
> {code} "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
> condition [0x7ff12694e000] java.lang.Thread.State: TIMED_WAITING
> (sleeping) at java.lang.Thread.sleep(Native Method) at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658) at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
> 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
> junit.framework.TestCase.runBare(TestCase.java:141) at
> junit.framework.TestResult$1.protect(TestResult.java:122) at
> junit.framework.TestResult.runProtected(TestResult.java:142) at
> junit.framework.TestResult.run(TestResult.java:125) at
> junit.framework.TestCase.run(TestCase.java:129) at
> junit.framework.TestSuite.runTest(TestSuite.java:255) at
> junit.framework.TestSuite.run(TestSuite.java:250) at
> junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.frame
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9018) PDS1 TC configuration hangs periodically
Eduard Shangareev created IGNITE-9018:
-
Summary: PDS1 TC configuration hangs periodically
Key: IGNITE-9018
URL: https://issues.apache.org/jira/browse/IGNITE-9018
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
At least one timeout was caused by next
{code} "main" #1 prio=5 os_prio=0 tid=0x7ff12000e000 nid=0xeaa waiting on
condition [0x7ff12694e000] java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method) at
org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7658) at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.doTestNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:375)
at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentedRingByteBufferTest.testNoOverflowMultiThreaded(SegmentedRingByteBufferTest.java:79)
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
junit.framework.TestCase.runBare(TestCase.java:141) at
junit.framework.TestResult$1.protect(TestResult.java:122) at
junit.framework.TestResult.runProtected(TestResult.java:142) at
junit.framework.TestResult.run(TestResult.java:125) at
junit.framework.TestCase.run(TestCase.java:129) at
junit.framework.TestSuite.runTest(TestSuite.java:255) at
junit.framework.TestSuite.run(TestSuite.java:250) at
junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.frame
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9017) .NET: Clear cache statistics
Denis Garus created IGNITE-9017: --- Summary: .NET: Clear cache statistics Key: IGNITE-9017 URL: https://issues.apache.org/jira/browse/IGNITE-9017 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7 Reporter: Denis Garus ICache.ClearStatistics, ICluster.ClearStatistics. See IGNITE-8705 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9016) Byte arrays are not working as cache keys
Evgenii Zhuravlev created IGNITE-9016:
-
Summary: Byte arrays are not working as cache keys
Key: IGNITE-9016
URL: https://issues.apache.org/jira/browse/IGNITE-9016
Project: Ignite
Issue Type: Bug
Reporter: Evgenii Zhuravlev
it's not possible to retrieve early inserted data with byte[] key:
{code:java}
IgniteCache cache = ignite.getOrCreateCache("test");
byte[] a = "test".getBytes();
cache.put(a, a);
cache.get(a); //returns null
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8999) WebConsole should correct parsing trace error messages introduced by #8971
[ https://issues.apache.org/jira/browse/IGNITE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546304#comment-16546304 ] Vasiliy Sisko commented on IGNITE-8999: --- Implemented processing of error messages with trace for Alerts and exception on query execution. > WebConsole should correct parsing trace error messages introduced by #8971 > -- > > Key: IGNITE-8999 > URL: https://issues.apache.org/jira/browse/IGNITE-8999 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Vasiliy Sisko >Priority: Major > > https://issues.apache.org/jira/browse/IGNITE-8971 added trace to error > messages, change to WC parsing is needed, see comments there -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7207) Exchange worker dies if index contains non existent field
[
https://issues.apache.org/jira/browse/IGNITE-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov resolved IGNITE-7207.
Resolution: Duplicate
Closing as a duplicate of IGNITE-1094.
> Exchange worker dies if index contains non existent field
> -
>
> Key: IGNITE-7207
> URL: https://issues.apache.org/jira/browse/IGNITE-7207
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Stanislav Lukyanov
>Priority: Major
> Attachments: Test.java
>
>
> If {{QueryEntity}} contains an index with a non existent field,
> {{createCache}} first throws this exception which is correct:
> {noformat}
> [2017-12-14
> 18:51:23,627][ERROR][exchange-worker-#42%null%][CacheAffinitySharedManager]
> Failed to initialize cache. Will try to rollback cache start routine.
> [cacheName=test]
> class org.apache.ignite.IgniteCheckedException: Field not found: a
> at
> org.apache.ignite.internal.processors.query.QueryIndexDescriptorImpl.addField(QueryIndexDescriptorImpl.java:124)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.createIndexDescriptor(QueryUtils.java:631)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.processIndex(QueryUtils.java:648)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.processIndexes(QueryUtils.java:584)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.processBinaryMeta(QueryUtils.java:542)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:438)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:687)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:836)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1816)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:882)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:588)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2278)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Field not found: a
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1327)
> at
> org.apache.ignite.internal.IgniteKernal.createCache(IgniteKernal.java:2817)
> at Test.main(Test.java:36)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class org.apache.ignite.IgniteCheckedException: Field not found: a
> at
> org.apache.ignite.internal.processors.query.QueryIndexDescriptorImpl.addField(QueryIndexDescriptorImpl.java:124)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.createIndexDescriptor(QueryUtils.java:631)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.processIndex(QueryUtils.java:648)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.processIndexes(QueryUtils.java:584)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.processBinaryMeta(QueryUtils.java:542)
> at
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:438)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:687)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:836)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:)
> at
>
[jira] [Resolved] (IGNITE-5026) getOrCreateCaches() hangs if any exception in GridDhtPartitionsExchangeFuture.init()
[
https://issues.apache.org/jira/browse/IGNITE-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-5026.
-
Resolution: Fixed
Fix Version/s: 2.7
merged into master branch
commit: a393e696212ef0dd4f23f923bf1001e0a48db915
> getOrCreateCaches() hangs if any exception in
> GridDhtPartitionsExchangeFuture.init()
>
>
> Key: IGNITE-5026
> URL: https://issues.apache.org/jira/browse/IGNITE-5026
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9, 2.0
>Reporter: Alexandr Kuramshin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.7
>
>
> Any exception has been thrown by {{GridDhtPartitionsExchangeFuture.init()}}
> causes to wait indefinitely {{GridCompoundFuture}} returned by
> {{GridCacheProcessor.dynamicStartCaches()}}.
> Reproduced by
> {{IgniteDynamicCacheStartSelfTest.testGetOrCreateCollectionExceptional()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-7196: --- Assignee: Maxim Muzafarov > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500, /127.0.0.1:48500, >
[jira] [Assigned] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-7196: Assignee: (was: Alexey Goncharuk) > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500, /127.0.0.1:48500, > ip-172-31-20-209.eu-central-1.compute.internal/172.31.20.209:48500], >
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546291#comment-16546291 ] Alexey Goncharuk commented on IGNITE-7196: -- No objections from my side, unassigned the ticket. > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500,
[jira] [Commented] (IGNITE-8684) Partition state exchange during rebalance continues to keep sending state messages (single,full) in loop even if no changes in partition states
[ https://issues.apache.org/jira/browse/IGNITE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546288#comment-16546288 ] Dmitriy Govorukhin commented on IGNITE-8684: [~agoncharuk] Could you please merge the changes? > Partition state exchange during rebalance continues to keep sending state > messages (single,full) in loop even if no changes in partition states > --- > > Key: IGNITE-8684 > URL: https://issues.apache.org/jira/browse/IGNITE-8684 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > This is due to invalid "changed" state computation in > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CachePartitionFullCountersMap, > java.util.Set, > org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-1553) Optimize transaction prepare step when store is enabled
[
https://issues.apache.org/jira/browse/IGNITE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-1553:
-
Attachment: Optimize-tx-prep-step-when-store-is-enabled.patch
> Optimize transaction prepare step when store is enabled
> ---
>
> Key: IGNITE-1553
> URL: https://issues.apache.org/jira/browse/IGNITE-1553
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: important
> Attachments: Optimize-tx-prep-step-when-store-is-enabled.patch
>
>
> Currently entries are enlisted in a database transaction after grid
> transaction is in PREPARED state. We can do this in parallel in the following
> fashion (pseudo-code):
> {code:java}
> fut = tx.prepareAsync();
> db.write(tx.writes());
> fut.get();
> try {
> db.commit();
>
> tx.commit();
> }
> catch (Exception e) {
> tx.rollback();
> }
> {code}
> If this approach is applied, we should be able to reduce latency for
> transactions when write-through is enabled.
>
> store prepare works on primary nodes only
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546286#comment-16546286 ] Dmitriy Pavlov commented on IGNITE-1094: [~agura] [~Jokser] [~slava.koptilin], this fix seems to fix test org.apache.ignite.internal.processors.cache.persistence.standbycluster.IgniteChangeGlobalStateTest#testActivateAfterFailGetLock, but I see this test still contains fail with link to this ticket. Am I missing something? > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8992) Wrong log when LongJVMPauseDetector stops the worker thread
[ https://issues.apache.org/jira/browse/IGNITE-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-8992: - Fix Version/s: 2.7 > Wrong log when LongJVMPauseDetector stops the worker thread > --- > > Key: IGNITE-8992 > URL: https://issues.apache.org/jira/browse/IGNITE-8992 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Minor > Fix For: 2.7 > > > When LongJVMPauseDetector stops the worker thread, a log will contain follow > error: > [2018-07-12 > 12:57:28,332][ERROR][jvm-pause-detector-worker][CacheMetricsEnableRuntimeTest1] > jvm-pause-detector-worker has been interrupted > java.lang.InterruptedException: sleep interrupted > at java.lang.Thread.sleep(Native Method) > at > org.apache.ignite.internal.LongJVMPauseDetector$1.run(LongJVMPauseDetector.java:97) > The error must be only if worker thread stopped unintentionally. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8992) Wrong log when LongJVMPauseDetector stops the worker thread
[ https://issues.apache.org/jira/browse/IGNITE-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-8992. -- Resolution: Fixed Merged to master. Thanks for contribution. > Wrong log when LongJVMPauseDetector stops the worker thread > --- > > Key: IGNITE-8992 > URL: https://issues.apache.org/jira/browse/IGNITE-8992 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Minor > > When LongJVMPauseDetector stops the worker thread, a log will contain follow > error: > [2018-07-12 > 12:57:28,332][ERROR][jvm-pause-detector-worker][CacheMetricsEnableRuntimeTest1] > jvm-pause-detector-worker has been interrupted > java.lang.InterruptedException: sleep interrupted > at java.lang.Thread.sleep(Native Method) > at > org.apache.ignite.internal.LongJVMPauseDetector$1.run(LongJVMPauseDetector.java:97) > The error must be only if worker thread stopped unintentionally. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8929) WAL should not disable for the group if none a partition is not assigned to a local node
[ https://issues.apache.org/jira/browse/IGNITE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546284#comment-16546284 ] ASF GitHub Bot commented on IGNITE-8929: GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/4372 IGNITE-8929 test reproducer + simple fix. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8929-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4372.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 #4372 commit 77f7a096935716ef2e3c81543ec6fd0018098a9c Author: Dmitriy Govorukhin Date: 2018-07-17T09:45:52Z IGNITE-8929 test reproducer + simple fix. WAL should not disable for the group if none a partition is not assigned to a local node. commit b3f4d9646533ceac563b4bb056163cff0d5e0091 Author: Dmitriy Govorukhin Date: 2018-07-17T09:48:31Z IGNITE-8929 Debug on before change WAL state > WAL should not disable for the group if none a partition is not assigned to a > local node > > > Key: IGNITE-8929 > URL: https://issues.apache.org/jira/browse/IGNITE-8929 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8975) Invalid initialization of compressed archived WAL segment when WAL compression is switched off.
[
https://issues.apache.org/jira/browse/IGNITE-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546281#comment-16546281
]
Sergey Chugunov commented on IGNITE-8975:
-
[~ivandasch], [~ivan.glukos],
I reviewed the ticket, change looks good to me, tests are provided (executed
them locally with/without functional change: they pass and fail as expected).
I restarted TC build as it had a timeout in Basic1 suite. If it passes with
acceptable overall status, we'll be good to proceed with merging.
> Invalid initialization of compressed archived WAL segment when WAL
> compression is switched off.
> ---
>
> Key: IGNITE-8975
> URL: https://issues.apache.org/jira/browse/IGNITE-8975
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.7
>
>
> After restarting node with WAL compression disabled and when compressed wal
> archive
> presentd, current implementation of FileWriteAheadLogManager ignores
> presenting compressed wal segment and initalizes empty brand new one. This
> causes following error:
> {code:java}
> 2018-07-05 16:14:25.761
> [ERROR][exchange-worker-#153%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.c.CheckpointHistory]
> Failed to process checkpoint: CheckpointEntry
> [id=8dc4b1cc-dedd-4a57-8748-f5a7ecfd389d, timestamp=1530785506909,
> ptr=FileWALPointer [idx=4520, fileOff=860507725, len=691515]]
> org.apache.ignite.IgniteCheckedException: Failed to find checkpoint record at
> the given WAL pointer: FileWALPointer [idx=4520, fileOff=860507725,
> len=691515]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.initIfNeeded(CheckpointEntry.java:346)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.access$300(CheckpointEntry.java:231)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.initIfNeeded(CheckpointEntry.java:123)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.groupState(CheckpointEntry.java:105)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.isCheckpointApplicableForGroup(CheckpointHistory.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.searchAndReserveCheckpoints(CheckpointHistory.java:304)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.reserveHistoryForExchange(GridCacheDatabaseSharedManager.java:1614)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:724)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2477)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2357)
> 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
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9014) CPP Thin: Thin client is not present in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546273#comment-16546273
]
ASF GitHub Bot commented on IGNITE-9014:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4371
> CPP Thin: Thin client is not present in binary release
> --
>
> Key: IGNITE-9014
> URL: https://issues.apache.org/jira/browse/IGNITE-9014
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> C++ thin client is not present in {{platforms/cpp}} upon binary release
> creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-1553) Optimize transaction prepare step when store is enabled
[
https://issues.apache.org/jira/browse/IGNITE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-1553:
Assignee: (was: Alexey Kuznetsov)
> Optimize transaction prepare step when store is enabled
> ---
>
> Key: IGNITE-1553
> URL: https://issues.apache.org/jira/browse/IGNITE-1553
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: important
>
> Currently entries are enlisted in a database transaction after grid
> transaction is in PREPARED state. We can do this in parallel in the following
> fashion (pseudo-code):
> {code:java}
> fut = tx.prepareAsync();
> db.write(tx.writes());
> fut.get();
> try {
> db.commit();
>
> tx.commit();
> }
> catch (Exception e) {
> tx.rollback();
> }
> {code}
> If this approach is applied, we should be able to reduce latency for
> transactions when write-through is enabled.
>
> store prepare works on primary nodes only
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8929) WAL should not disable for the group if none a partition is not assigned to a local node
[ https://issues.apache.org/jira/browse/IGNITE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546271#comment-16546271 ] ASF GitHub Bot commented on IGNITE-8929: Github user DmitriyGovorukhin closed the pull request at: https://github.com/apache/ignite/pull/4305 > WAL should not disable for the group if none a partition is not assigned to a > local node > > > Key: IGNITE-8929 > URL: https://issues.apache.org/jira/browse/IGNITE-8929 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-809) Old value can be missed for tx near cache entry
[
https://issues.apache.org/jira/browse/IGNITE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546263#comment-16546263
]
ASF GitHub Bot commented on IGNITE-809:
---
Github user voipp closed the pull request at:
https://github.com/apache/ignite/pull/4273
> Old value can be missed for tx near cache entry
> ---
>
> Key: IGNITE-809
> URL: https://issues.apache.org/jira/browse/IGNITE-809
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Artem Shutak
>Priority: Major
> Labels: Muted_test
>
> GridCacheMultinodeUpdateNearEnabledSelfTest fails.
> {noformat}
> junit.framework.AssertionFailedError: Got null in processor.
> at
> org.apache.ignite.internal.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest.testInvoke(GridCacheMultinodeUpdateAbstractSelfTest.java:98)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1361)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:67)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.run(GridAbstractTest.java:1304)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9014) CPP Thin: Thin client is not present in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546256#comment-16546256
]
Igor Sapego commented on IGNITE-9014:
-
[~gvvinblade], can you review?
> CPP Thin: Thin client is not present in binary release
> --
>
> Key: IGNITE-9014
> URL: https://issues.apache.org/jira/browse/IGNITE-9014
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> C++ thin client is not present in {{platforms/cpp}} upon binary release
> creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8684) Partition state exchange during rebalance continues to keep sending state messages (single,full) in loop even if no changes in partition states
[ https://issues.apache.org/jira/browse/IGNITE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546254#comment-16546254 ] Alexey Goncharuk commented on IGNITE-8684: -- Looks good to me now > Partition state exchange during rebalance continues to keep sending state > messages (single,full) in loop even if no changes in partition states > --- > > Key: IGNITE-8684 > URL: https://issues.apache.org/jira/browse/IGNITE-8684 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > This is due to invalid "changed" state computation in > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CachePartitionFullCountersMap, > java.util.Set, > org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9014) CPP Thin: Thin client is not present in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546257#comment-16546257
]
Igor Seliverstov commented on IGNITE-9014:
--
[~isapego], looks OK to me
> CPP Thin: Thin client is not present in binary release
> --
>
> Key: IGNITE-9014
> URL: https://issues.apache.org/jira/browse/IGNITE-9014
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> C++ thin client is not present in {{platforms/cpp}} upon binary release
> creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9014) CPP Thin: Thin client is not present in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546242#comment-16546242
]
ASF GitHub Bot commented on IGNITE-9014:
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/4371
IGNITE-9014: Thin С++ client included in binary release
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9014
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4371.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 #4371
commit f3542094e379ce4c77e037ffaed698f25ece78c4
Author: Igor Sapego
Date: 2018-07-17T09:23:35Z
IGNITE-9014: Fixed
> CPP Thin: Thin client is not present in binary release
> --
>
> Key: IGNITE-9014
> URL: https://issues.apache.org/jira/browse/IGNITE-9014
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> C++ thin client is not present in {{platforms/cpp}} upon binary release
> creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9014) CPP Thin: Thin client is not present in binary release
Igor Sapego created IGNITE-9014:
---
Summary: CPP Thin: Thin client is not present in binary release
Key: IGNITE-9014
URL: https://issues.apache.org/jira/browse/IGNITE-9014
Project: Ignite
Issue Type: Bug
Components: platforms
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.7
C++ thin client is not present in {{platforms/cpp}} upon binary release
creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8929) WAL should not disable for the group if none a partition is not assigned to a local node
[ https://issues.apache.org/jira/browse/IGNITE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546222#comment-16546222 ] Dmitriy Govorukhin commented on IGNITE-8929: [~agoncharuk] Please review my changes. > WAL should not disable for the group if none a partition is not assigned to a > local node > > > Key: IGNITE-8929 > URL: https://issues.apache.org/jira/browse/IGNITE-8929 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8853) Test CacheSerializableTransactionsTest#testIncrementTxRestart fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-8853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov resolved IGNITE-8853.
-
Resolution: Duplicate
Fix Version/s: 2.7
> Test CacheSerializableTransactionsTest#testIncrementTxRestart fails on TC
> -
>
> Key: IGNITE-8853
> URL: https://issues.apache.org/jira/browse/IGNITE-8853
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Test started to fail after implementing IGNITE-8657.
> There is the following message in logs that makes it clear what happens:
> {noformat}
> junit.framework.AssertionFailedError: Unexpected exception [err=class
> org.apache.ignite.IgniteException: Node need try to reconnect
> [nodeId=5a7cfccb-d87e-4d2a-b044-f0a43e36], cause=class
> org.apache.ignite.internal.IgniteNeedReconnectException: Node need try to
> reconnect [nodeId=5a7cfccb-d87e-4d2a-b044-f0a43e36]]
> {noformat}
> IGNITE-8657 fixed issue with client nodes hanging when their initial
> ExchangeFutures were preempted from exchange queue on coordinator because of
> EXCHANGE_HISTORY setting.
> It turned out that for some reason client may be instructed to reconnect even
> when it has already joined topology but now server node joining or leaving it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
