[jira] [Assigned] (IGNITE-10691) thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or C++ client
[
https://issues.apache.org/jira/browse/IGNITE-10691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Petroshenko reassigned IGNITE-10691:
--
Assignee: Alexey Kosenchuk
> thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or
> C++ client
> -
>
> Key: IGNITE-10691
> URL: https://issues.apache.org/jira/browse/IGNITE-10691
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Alexey Kosenchuk
>Priority: Major
> Fix For: 2.8
>
>
> Trying to put uuid with PY or PHP or NodeJS client and get from Java or C++
> client have different results
> Python put
> {code}
> cache = client.get_or_create_cache("UUID_PY")
> cache.put(1, UUID("d597be47-949e-475b-8918-44ca836798a3"),
> key_hint=IntObject, value_hint=UUIDObject)
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PY");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> 5b479e94-47be-97d5-a398-6783ca441889
> {code}
> Same for C++ thin client
> And they looks like mixed up in a different order
> Python: {code}d597be47-949e-475b-8918-44ca836798a3{code}
> Java: {code}5b479e94-47be-97d5-a398-6783ca441889{code}
> For example take "ca" in 7-8 number from the end of java uuid
> On left we have "83", but in python "83" stay on right side from "ca"
> Different for "44" which is on right for Java but on left for Python
> NodeJS put
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_JS"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> key = 1;
> value = [95,190,238,78,178,166,68,220,153,172,100,68,215,254,125,246];
> await cache.put(key, value);
> {code}
> Py get
> {code}
> cache = client.get_or_create_cache("UUID_JS")
> result = cache.get(1, key_hint=IntObject)
> print(result)
> {code}
> Py output
> {code}
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_JS");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc44a6b2-4eee-be5f-f67d-fed74464ac99
> {code}
> PHP put
> [238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205] =
> "ee0f2fed-e07a-42dc-aa59-7f8fc7380acd"
> {code}
> $cache =
> $client->getOrCreateCache("UUID_PH")->setKeyType(ObjectType::INTEGER)->setValueType(ObjectType::UUID);
> $cache->put(1,[238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205]);
> {code}
> JS get
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_PH"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> result = (await cache.get(1));
> {code}
> JS output
> {code}
> 238 15 47 237 224 122 66 220 170 89 127 143 199 56 10 205
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PH");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc427ae0-ed2f-0fee-cd0a-38c78f7f59aa
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10691) thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or C++ client
[
https://issues.apache.org/jira/browse/IGNITE-10691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792347#comment-16792347
]
Pavel Petroshenko commented on IGNITE-10691:
As IGNITE-10721 is fixed, this one can be addressed as well.
> thin clients: PY, PHP and NodeJS clients mixed up UUID taken from Java or
> C++ client
> -
>
> Key: IGNITE-10691
> URL: https://issues.apache.org/jira/browse/IGNITE-10691
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Alexey Kosenchuk
>Priority: Major
> Fix For: 2.8
>
>
> Trying to put uuid with PY or PHP or NodeJS client and get from Java or C++
> client have different results
> Python put
> {code}
> cache = client.get_or_create_cache("UUID_PY")
> cache.put(1, UUID("d597be47-949e-475b-8918-44ca836798a3"),
> key_hint=IntObject, value_hint=UUIDObject)
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PY");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> 5b479e94-47be-97d5-a398-6783ca441889
> {code}
> Same for C++ thin client
> And they looks like mixed up in a different order
> Python: {code}d597be47-949e-475b-8918-44ca836798a3{code}
> Java: {code}5b479e94-47be-97d5-a398-6783ca441889{code}
> For example take "ca" in 7-8 number from the end of java uuid
> On left we have "83", but in python "83" stay on right side from "ca"
> Different for "44" which is on right for Java but on left for Python
> NodeJS put
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_JS"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> key = 1;
> value = [95,190,238,78,178,166,68,220,153,172,100,68,215,254,125,246];
> await cache.put(key, value);
> {code}
> Py get
> {code}
> cache = client.get_or_create_cache("UUID_JS")
> result = cache.get(1, key_hint=IntObject)
> print(result)
> {code}
> Py output
> {code}
> 5fbeee4e-b2a6-44dc-99ac-6444d7fe7df6
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_JS");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc44a6b2-4eee-be5f-f67d-fed74464ac99
> {code}
> PHP put
> [238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205] =
> "ee0f2fed-e07a-42dc-aa59-7f8fc7380acd"
> {code}
> $cache =
> $client->getOrCreateCache("UUID_PH")->setKeyType(ObjectType::INTEGER)->setValueType(ObjectType::UUID);
> $cache->put(1,[238,15,47,237,224,122,66,220,170,89,127,143,199,56,10,205]);
> {code}
> JS get
> {code}
> cache = (await igniteClient.getOrCreateCache("UUID_PH"))
> .setKeyType(ObjectType.PRIMITIVE_TYPE.INTEGER)
> .setValueType(ObjectType.PRIMITIVE_TYPE.UUID);
> result = (await cache.get(1));
> {code}
> JS output
> {code}
> 238 15 47 237 224 122 66 220 170 89 127 143 199 56 10 205
> {code}
> Java get
> {code}
> ClientCache cache = igniteClient.getOrCreateCache("UUID_PH");
> UUID id = cache.get(1);
> System.out.println(id);
> {code}
> Java output
> {code}
> dc427ae0-ed2f-0fee-cd0a-38c78f7f59aa
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11435) SQL: Create a view with query history
[
https://issues.apache.org/jira/browse/IGNITE-11435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791345#comment-16791345
]
Ignite TC Bot commented on IGNITE-11435:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3296639buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Create a view with query history
> -
>
> Key: IGNITE-11435
> URL: https://issues.apache.org/jira/browse/IGNITE-11435
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 1.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY
> List of columns:
> SCHEMA_NAME - name of schema
> QUERY - query text
> LOCAL - flag of local query
> CALLS - number of execution of the query
> FAILURES - number of failures for the query
> DURATION_MIN - minimum duration of execution
> DURATION_MAX - maximum duration of execution
> LAST_QUERY_START - time of the last start of execution
>
> see QueryHistoryMetrics class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7139) SQL: Implement a lazy execution for the local queries.
[
https://issues.apache.org/jira/browse/IGNITE-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-7139:
-
Fix Version/s: 2.8
> SQL: Implement a lazy execution for the local queries.
> --
>
> Key: IGNITE-7139
> URL: https://issues.apache.org/jira/browse/IGNITE-7139
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment a lazy execution is implemented for the distributed queries
> only (see {{GridMapQueryExecutor}}). We need to add this feature for the
> local queries too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11435) SQL: Create a view with query history
[
https://issues.apache.org/jira/browse/IGNITE-11435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791410#comment-16791410
]
Vladimir Ozerov edited comment on IGNITE-11435 at 3/13/19 7:42 AM:
---
[~jooger], my comments:
# {{LOCAL_SQL_QUERY_HISTORY.QUERY}} should be renamed to {{SQL}} to be
consistent with running queries view
# {{LAST_QUERY_START}} should be {{LAST_START_TIME}} for the same reason as p.1
# {{CALLS}} is misleading term here, because in SQL "call" typically means
execution of a stored procedure. Let's rename it to {{EXECUTIONS}}
# {{EXECUTIONS}} and {{FAILURES}} should be {{long}}, not {{int}}, because it
is very easy to exceed Integer.MAX_VALUE. {{QueryHistoryMetrics}} and
{{QueryHistoryMetricsValue}} should be fixed accordingly.
# Test coverage is insufficient. We should test increment of executions and
failures, min and max duration changes, proper handling of schemas. Probably
custom SQL functions will be needed to test failures and durations.
was (Author: vozerov):
[~jooger], my comments:
# {{LOCAL_SQL_QUERY_HISTORY.QUERY}} should be renamed to {{SQL}} to be
consistent with running queries view
# {{LAST_QUERY_START}} should be {{LAST_START_TIME}} for the same reason as p.1
# {{CALLS}} is misleading term here, because in SQL "call" typically means
execution of a stored procedure. Let's rename it to {{EXECUTIONS}}
# {{EXECUTIONS}} and {{FAILURES}} should be {{long}}, not {{int}}, because it
is very easy to exceed Integer.MAX_VALUE. {{QueryHistoryMetrics}} and
{{QueryHistoryMetricsValue}} should be fixed accordingly.
> SQL: Create a view with query history
> -
>
> Key: IGNITE-11435
> URL: https://issues.apache.org/jira/browse/IGNITE-11435
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY
> List of columns:
> SCHEMA_NAME - name of schema
> QUERY - query text
> LOCAL - flag of local query
> CALLS - number of execution of the query
> FAILURES - number of failures for the query
> DURATION_MIN - minimum duration of execution
> DURATION_MAX - maximum duration of execution
> LAST_QUERY_START - time of the last start of execution
>
> see QueryHistoryMetrics class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
[
https://issues.apache.org/jira/browse/IGNITE-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791375#comment-16791375
]
Ivan Pavlukhin commented on IGNITE-11534:
-
[~DmitriyGovorukhin], TC results are ready. Also, I ignored some test methods
which fail in MVCC suites, attention will be taken in separate ticket related
to MVCC. Please take a look.
> Partition loss policy is not handled properly for implicit single key
> transactions
> --
>
> Key: IGNITE-11534
> URL: https://issues.apache.org/jira/browse/IGNITE-11534
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in handling partition loss policies for single put operations
> over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
> improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11428) Schemas don't show in Dbeaver
[ https://issues.apache.org/jira/browse/IGNITE-11428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791405#comment-16791405 ] Vladimir Ozerov commented on IGNITE-11428: -- [~jooger], as tests are invalid due to IGNITE-11441, please re-submit it for review once IGNITE-11441 is merged. > Schemas don't show in Dbeaver > - > > Key: IGNITE-11428 > URL: https://issues.apache.org/jira/browse/IGNITE-11428 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > At Database navigator tab we can see just single schema PUBLIC. Need to add > to jdbc driver support show all schemas except INFORMATIONAL, due to it H2 > schema and contains incorrect information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
[
https://issues.apache.org/jira/browse/IGNITE-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-11534:
Ignite Flags: (was: Docs Required)
> Partition loss policy is not handled properly for implicit single key
> transactions
> --
>
> Key: IGNITE-11534
> URL: https://issues.apache.org/jira/browse/IGNITE-11534
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in handling partition loss policies for single put operations
> over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
> improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
[
https://issues.apache.org/jira/browse/IGNITE-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791440#comment-16791440
]
Dmitriy Govorukhin commented on IGNITE-11534:
-
[~Pavlukhin] Thanks for the contribution, merged to master.
> Partition loss policy is not handled properly for implicit single key
> transactions
> --
>
> Key: IGNITE-11534
> URL: https://issues.apache.org/jira/browse/IGNITE-11534
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in handling partition loss policies for single put operations
> over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
> improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
[
https://issues.apache.org/jira/browse/IGNITE-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791373#comment-16791373
]
Ignite TC Bot commented on IGNITE-11534:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3298002buildTypeId=IgniteTests24Java8_RunAll]
> Partition loss policy is not handled properly for implicit single key
> transactions
> --
>
> Key: IGNITE-11534
> URL: https://issues.apache.org/jira/browse/IGNITE-11534
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in handling partition loss policies for single put operations
> over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
> improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11435) SQL: Create a view with query history
[ https://issues.apache.org/jira/browse/IGNITE-11435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11435: - Fix Version/s: (was: 1.8) 2.8 > SQL: Create a view with query history > - > > Key: IGNITE-11435 > URL: https://issues.apache.org/jira/browse/IGNITE-11435 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY > List of columns: > SCHEMA_NAME - name of schema > QUERY - query text > LOCAL - flag of local query > CALLS - number of execution of the query > FAILURES - number of failures for the query > DURATION_MIN - minimum duration of execution > DURATION_MAX - maximum duration of execution > LAST_QUERY_START - time of the last start of execution > > see QueryHistoryMetrics class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11188) Optimize baseline autoadjustment for in-memory clusters with zero timeout
[
https://issues.apache.org/jira/browse/IGNITE-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791441#comment-16791441
]
Ignite TC Bot commented on IGNITE-11188:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3286254buildTypeId=IgniteTests24Java8_RunAll]
> Optimize baseline autoadjustment for in-memory clusters with zero timeout
> -
>
> Key: IGNITE-11188
> URL: https://issues.apache.org/jira/browse/IGNITE-11188
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
>
> In current implementation (IGNITE-8571) zero-timeout case initiates two
> partition map exchanges on join/leave node events. This could be improved so
> that baseline is updated at the same time as join/leave event processing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10161) Be able to cancel any query by query id
[
https://issues.apache.org/jira/browse/IGNITE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791448#comment-16791448
]
Vladimir Ozerov commented on IGNITE-10161:
--
[~jooger], my comments:
# {{SqlParserDropIndexSelfTest}} - exception is removed from signature, but
JavaDoc is not fixed
# I am not sure there are tests for client disconnect. Do we have them?
# {{CommandProcessor.onDisconnected}} - error message is misleading, we do not
know whether query was cancelled or not. I would rewrite it as "Failed to
cancel query because local client node has been disconnected from the cluster"
Otherwise looks good.
> Be able to cancel any query by query id
> ---
>
> Key: IGNITE-10161
> URL: https://issues.apache.org/jira/browse/IGNITE-10161
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User should be able to cancel any query by query id through SQL command.
> SQL syntax: *KILL QUERY \{ASYNC} '<_query_id>'_*
> _ASYNC_ is optional parameter which return control immediately without
> waiting real cancellation will be done.
> By default, without ASYNC parameter, the request is blocking untill
> cancellation is not done.
> Query should be canceled together with its parts on all nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11460:
--
Attachment: stacktraces.log
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments: stacktraces.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
[
https://issues.apache.org/jira/browse/IGNITE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791473#comment-16791473
]
Ignite TC Bot commented on IGNITE-10104:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3299000buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: client SFU doesn't work on replicated caches
> -
>
> Key: IGNITE-10104
> URL: https://issues.apache.org/jira/browse/IGNITE-10104
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: transactions
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When select for update executes from client node the execution is sent to
> random owning node. On that node dht enlist operation is started what causes
> an assertion error because dht enlist operation implies that the node is
> primary for all processed keys.
> see
> {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11377) Display time to baseline auto-adjust event in console.sh
[ https://issues.apache.org/jira/browse/IGNITE-11377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791498#comment-16791498 ] Dmitriy Govorukhin commented on IGNITE-11377: - [~akalashnikov] Thanks for the contribution, merged to master. > Display time to baseline auto-adjust event in console.sh > > > Key: IGNITE-11377 > URL: https://issues.apache.org/jira/browse/IGNITE-11377 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > It required to add information about next auto-adjust. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11536) Add information about possible long GC pause to checkpoint started message.
Sergey Antonov created IGNITE-11536:
---
Summary: Add information about possible long GC pause to
checkpoint started message.
Key: IGNITE-11536
URL: https://issues.apache.org/jira/browse/IGNITE-11536
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
One of possible reasons long hold of write lock on checkpoint is GC pause. Now
you must check logs around on {{Possible too long JVM pause}} message. We
should print possible long GC pause time in {{Checkpoint started}} message, if
threshhold was passed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11079) MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
[
https://issues.apache.org/jira/browse/IGNITE-11079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11079:
--
Fix Version/s: 2.8
> MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
> --
>
> Key: IGNITE-11079
> URL: https://issues.apache.org/jira/browse/IGNITE-11079
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See Tc run
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=925274886589214180=testDetails]
> Test fails after series of long JVM pauses with stacktrace:
> {code:java}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryBackupQueueTest.testManyQueryBackupQueue(IgniteCacheContinuousQueryBackupQueueTest.java:175)
> 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
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11524) Memory leak caused by executing a jdbc prepared statement
[ https://issues.apache.org/jira/browse/IGNITE-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11524: - Component/s: (was: thin client) jdbc > Memory leak caused by executing a jdbc prepared statement > - > > Key: IGNITE-11524 > URL: https://issues.apache.org/jira/browse/IGNITE-11524 > Project: Ignite > Issue Type: Bug > Components: jdbc, sql >Reporter: Pavel Vinokurov >Priority: Blocker > Fix For: 2.8 > > Attachments: PreparedStatementOOMReproducer.java > > > Executing a prepared statement multiple times lead to OOM. > VisualVM indicates that heap contains a lot of JdbcThinPreparedStatament > objects. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11524) Memory leak caused by executing a jdbc prepared statement
[ https://issues.apache.org/jira/browse/IGNITE-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11524: - Ignite Flags: (was: Docs Required) > Memory leak caused by executing a jdbc prepared statement > - > > Key: IGNITE-11524 > URL: https://issues.apache.org/jira/browse/IGNITE-11524 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Pavel Vinokurov >Priority: Blocker > Fix For: 2.8 > > Attachments: PreparedStatementOOMReproducer.java > > > Executing a prepared statement multiple times lead to OOM. > VisualVM indicates that heap contains a lot of JdbcThinPreparedStatament > objects. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11524) Memory leak caused by executing a jdbc prepared statement
[ https://issues.apache.org/jira/browse/IGNITE-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-11524: Assignee: Taras Ledkov > Memory leak caused by executing a jdbc prepared statement > - > > Key: IGNITE-11524 > URL: https://issues.apache.org/jira/browse/IGNITE-11524 > Project: Ignite > Issue Type: Bug > Components: jdbc, sql >Reporter: Pavel Vinokurov >Assignee: Taras Ledkov >Priority: Blocker > Fix For: 2.8 > > Attachments: PreparedStatementOOMReproducer.java > > > Executing a prepared statement multiple times lead to OOM. > VisualVM indicates that heap contains a lot of JdbcThinPreparedStatament > objects. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11391) Test on free list is freezes sometimes
[ https://issues.apache.org/jira/browse/IGNITE-11391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11391: Fix Version/s: 2.8 > Test on free list is freezes sometimes > -- > > Key: IGNITE-11391 > URL: https://issues.apache.org/jira/browse/IGNITE-11391 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > CheckpointFreeListTest#testRestoreFreeListCorrectlyAfterRandomStop - freezed > sometimes > CheckpointFreeListTest.testFreeListRestoredCorrectly - flaky -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11391) Test on free list is freezes sometimes
[ https://issues.apache.org/jira/browse/IGNITE-11391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791560#comment-16791560 ] Dmitriy Govorukhin commented on IGNITE-11391: - [~akalashnikov] LGTM, thanks for the contribution, merged to master. > Test on free list is freezes sometimes > -- > > Key: IGNITE-11391 > URL: https://issues.apache.org/jira/browse/IGNITE-11391 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > CheckpointFreeListTest#testRestoreFreeListCorrectlyAfterRandomStop - freezed > sometimes > CheckpointFreeListTest.testFreeListRestoredCorrectly - flaky -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11441) ignite-sys-cache present in SQL schemas
[ https://issues.apache.org/jira/browse/IGNITE-11441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791584#comment-16791584 ] Yury Gerzhedovich edited comment on IGNITE-11441 at 3/13/19 11:10 AM: -- [~vozerov], # Fixed # As agreed now we will create schema for cache in case either schema name or query entity or function set for cache configuration. Waiting a Bot vise. was (Author: jooger): [~vozerov], # Fixed # As agreed now we will create schema for cache in case either schema name or query entity or function set for cache configuration. > ignite-sys-cache present in SQL schemas > --- > > Key: IGNITE-11441 > URL: https://issues.apache.org/jira/browse/IGNITE-11441 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Time Spent: 10m > Remaining Estimate: 0h > > Investigate why ignite-sys-cache (and possible other caches without > configured QueryEntity) are displayed in schemas. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11441) ignite-sys-cache present in SQL schemas
[ https://issues.apache.org/jira/browse/IGNITE-11441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791584#comment-16791584 ] Yury Gerzhedovich commented on IGNITE-11441: [~vozerov], # Fixed # As agreed now we will create schema for cache in case either schema name or query entity or function set for cache configuration. > ignite-sys-cache present in SQL schemas > --- > > Key: IGNITE-11441 > URL: https://issues.apache.org/jira/browse/IGNITE-11441 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Time Spent: 10m > Remaining Estimate: 0h > > Investigate why ignite-sys-cache (and possible other caches without > configured QueryEntity) are displayed in schemas. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11471) JDBC: Thin driver should start with a random server to connect
[
https://issues.apache.org/jira/browse/IGNITE-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791518#comment-16791518
]
Ignite TC Bot commented on IGNITE-11471:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3297736buildTypeId=IgniteTests24Java8_RunAll]
> JDBC: Thin driver should start with a random server to connect
> --
>
> Key: IGNITE-11471
> URL: https://issues.apache.org/jira/browse/IGNITE-11471
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Reporter: Stanislav Lukyanov
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Thin JDBC driver uses a list of server addresses to connect to. Connections
> created in a single JVM will use round-robin to choose the server to connect,
> yielding a uniform distribution. However, the round-robin always starts from
> the first server in the list. It means that multiple JVMs with the same JDBC
> connection URL and one connection each will all connect to the same server.
> Need to choose the first server randomly to have a better distribution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7139) SQL: Implement a lazy execution for the local queries.
[
https://issues.apache.org/jira/browse/IGNITE-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791605#comment-16791605
]
Taras Ledkov commented on IGNITE-7139:
--
[~vozerov], please review the patch.
> SQL: Implement a lazy execution for the local queries.
> --
>
> Key: IGNITE-7139
> URL: https://issues.apache.org/jira/browse/IGNITE-7139
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment a lazy execution is implemented for the distributed queries
> only (see {{GridMapQueryExecutor}}). We need to add this feature for the
> local queries too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7139) SQL: Implement a lazy execution for the local queries.
[
https://issues.apache.org/jira/browse/IGNITE-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791604#comment-16791604
]
Ignite TC Bot commented on IGNITE-7139:
---
{panel:title=- Run :: SQL: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *- Run :: SQL*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3297885buildTypeId=IgniteTests24Java8_RunAllSql]
> SQL: Implement a lazy execution for the local queries.
> --
>
> Key: IGNITE-7139
> URL: https://issues.apache.org/jira/browse/IGNITE-7139
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment a lazy execution is implemented for the distributed queries
> only (see {{GridMapQueryExecutor}}). We need to add this feature for the
> local queries too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
[
https://issues.apache.org/jira/browse/IGNITE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791474#comment-16791474
]
Roman Kondakov commented on IGNITE-10104:
-
[~amashenkov], misprint is fixed, merged with the latest master. Ready for
review. Thank you.
> MVCC TX: client SFU doesn't work on replicated caches
> -
>
> Key: IGNITE-10104
> URL: https://issues.apache.org/jira/browse/IGNITE-10104
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: transactions
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When select for update executes from client node the execution is sent to
> random owning node. On that node dht enlist operation is started what causes
> an assertion error because dht enlist operation implies that the node is
> primary for all processed keys.
> see
> {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11471) JDBC: Thin driver should start with a random server to connect
[
https://issues.apache.org/jira/browse/IGNITE-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791475#comment-16791475
]
Ignite TC Bot commented on IGNITE-11471:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=3297710]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3297736buildTypeId=IgniteTests24Java8_RunAll]
> JDBC: Thin driver should start with a random server to connect
> --
>
> Key: IGNITE-11471
> URL: https://issues.apache.org/jira/browse/IGNITE-11471
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Reporter: Stanislav Lukyanov
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Thin JDBC driver uses a list of server addresses to connect to. Connections
> created in a single JVM will use round-robin to choose the server to connect,
> yielding a uniform distribution. However, the round-robin always starts from
> the first server in the list. It means that multiple JVMs with the same JDBC
> connection URL and one connection each will all connect to the same server.
> Need to choose the first server randomly to have a better distribution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11532) Performance trace of executed query
[ https://issues.apache.org/jira/browse/IGNITE-11532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11532: --- Description: Need to add ability to trace and view performance of execution of SQL query with splitting by sql fragments. Additional details will be added after more deep investigate what exists in products another DB vendors. As start point can be used MySql logging - https://dev.mysql.com/doc/refman/8.0/en/server-logs.html was: Need to add ability to trace and view performance of execution of SQL query with splitting by sql fragments. Additional details will be added after more deep investigate what exists in products another DB vendors. > Performance trace of executed query > --- > > Key: IGNITE-11532 > URL: https://issues.apache.org/jira/browse/IGNITE-11532 > Project: Ignite > Issue Type: Task >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > > Need to add ability to trace and view performance of execution of SQL query > with splitting by sql fragments. > > Additional details will be added after more deep investigate what exists in > products another DB vendors. > As start point can be used MySql logging - > https://dev.mysql.com/doc/refman/8.0/en/server-logs.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7664) SQL: throw sane exception on unsupported SQL statements
[
https://issues.apache.org/jira/browse/IGNITE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791540#comment-16791540
]
Vladimir Ozerov commented on IGNITE-7664:
-
[~tledkov-gridgain], please see my comments below. Looks good to me in general,
but some polishing is needed.
# {{SqlParser}} - "are not supported" -> "is not supported"
# {{QueryParser.parseNative}} - {{catch (IgniteSQLException e)}} block looks
incorrect. By the contract, if any parsing error occurrs, we should throw
{{IgniteSQLException}} with proper code. This block could be removed if correct
exception is thrown form parser, which is {{SqlStrictParseException}} in this
case
# {{GridSqlQueryParser.parseCreateTable}} - separate exception should be thrown
for any unsupported keyword with as simple error message as possible
(" keyword is not supported")
# {{GridSqlQueryParser.parseAddColumn}} - same as previous point. We should
throw highly specialized error messages for the sake of consistency with other
parsing logic.
> SQL: throw sane exception on unsupported SQL statements
> ---
>
> Key: IGNITE-7664
> URL: https://issues.apache.org/jira/browse/IGNITE-7664
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Alexander Paschenko
>Assignee: Taras Ledkov
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Inspired by this SO issue:
> [https://stackoverflow.com/questions/48708238/ignite-database-create-schema-assertionerror]
> We should handle unsupported stuff more gracefully both in core code and
> drivers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11460:
--
Attachment: stacktraces.log
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments: stacktraces.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11460:
--
Attachment: (was: stacktraces.log)
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments: stacktraces.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11416) DistributedMetaStorage improvements
[ https://issues.apache.org/jira/browse/IGNITE-11416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11416: Fix Version/s: 2.8 > DistributedMetaStorage improvements > --- > > Key: IGNITE-11416 > URL: https://issues.apache.org/jira/browse/IGNITE-11416 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We need following improvements: > * do not write the same value twice in a row, this would lead to history > pollution; > * add "putAll" functionality on binary level, not in public API yet. This > would simplify the migration in future; > * do not use "*HistoryItem" class for everything, this is not conventional; > * retrieve "dmsVer" from cluster on handshake, this would help to reduce > joining node DataBag size drastically; > * add "isEmpty()" or "long getVersion()" method to metastorage, will be > helpful for components that use it; > * there has to be an ability to read data on client nodes, maybe write as > well, not sure yet; > * implement more optimal in-memory storage for history cache; > * start in-memory metastorage at proper time, current implementation does it > a bit too late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5962) Increase max length of index name
[ https://issues.apache.org/jira/browse/IGNITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791554#comment-16791554 ] Vladimir Ozerov commented on IGNITE-5962: - [~pkouznet], what TC bot says about test run? > Increase max length of index name > - > > Key: IGNITE-5962 > URL: https://issues.apache.org/jira/browse/IGNITE-5962 > Project: Ignite > Issue Type: Improvement > Components: general, sql >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Pavel Kuznetsov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In https://issues.apache.org/jira/browse/IGNITE-5941 max index name length > was reduced from 768 to 256 bytes. If we need to support longer names, we > need to change format of metastore data pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10991) JDBC thin: STREAMING mode fails on streamer reopen on not ordered mode
[
https://issues.apache.org/jira/browse/IGNITE-10991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791609#comment-16791609
]
Ignite TC Bot commented on IGNITE-10991:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3297500buildTypeId=IgniteTests24Java8_RunAll]
> JDBC thin: STREAMING mode fails on streamer reopen on not ordered mode
> --
>
> Key: IGNITE-10991
> URL: https://issues.apache.org/jira/browse/IGNITE-10991
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Attachments: CacheSqlStreamingAllowOverwriteTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Please see attached test. Repeatedly overwriting same cache entries over and
> over in streaming mode with ALLOW_OVERWRITE ON will cause either:
> {code}
> java.sql.BatchUpdateException: Failed to INSERT some keys because they are
> already in cache [keys=[2054...]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1052)
> ... 1 more
> {code}
> or
> {code}
> WARNING: Exception during batch send on streamed connection close
> java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: Data streamer has been closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1016)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Expecter behavior - no failures, all records overwritten.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10991) JDBC thin: STREAMING mode fails on streamer reopen on not ordered mode
[
https://issues.apache.org/jira/browse/IGNITE-10991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791618#comment-16791618
]
Taras Ledkov commented on IGNITE-10991:
---
[~vozerov], header & javadoc are fixed. Please take a look.
> JDBC thin: STREAMING mode fails on streamer reopen on not ordered mode
> --
>
> Key: IGNITE-10991
> URL: https://issues.apache.org/jira/browse/IGNITE-10991
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Attachments: CacheSqlStreamingAllowOverwriteTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Please see attached test. Repeatedly overwriting same cache entries over and
> over in streaming mode with ALLOW_OVERWRITE ON will cause either:
> {code}
> java.sql.BatchUpdateException: Failed to INSERT some keys because they are
> already in cache [keys=[2054...]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1052)
> ... 1 more
> {code}
> or
> {code}
> WARNING: Exception during batch send on streamed connection close
> java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: Data streamer has been closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1016)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Expecter behavior - no failures, all records overwritten.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11535) AtomicLong cannot be found after creation
[
https://issues.apache.org/jira/browse/IGNITE-11535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-11535:
-
Description:
For now, IgniteAtomics use {{PartitionLossPolicy.IGNORE}}, which is the default
value for all caches, (see {{DataStructuresProcessor#cacheConfiguration}}).
Therefore, partition loss leads to the fact that information about IgniteAtomic
may be lost as well. In that case, any operation with IgniteAtomic results in
the following exception:
{code:java}
Value: An error occurred while calling o2248.incrementAndGet.
: class org.apache.ignite.IgniteException: Failed to find atomic long:
nodeIdFilter_7
at
org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl.incrementAndGet(GridCacheAtomicLongImpl.java:105)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
at py4j.Gateway.invoke(Gateway.java:282)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.GatewayConnection.run(GatewayConnection.java:238)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.cache.processor.EntryProcessorException: Failed to find atomic
long: nodeIdFilter_7
at
org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:525)
at
org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:512)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:424)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1237)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:677)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1054)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:396)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:519)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
... 1 more
{code}
The bad news is that this IgniteAtomic cannot be removed or recreated on the
same node.
> AtomicLong cannot be found after creation
> -
>
> Key: IGNITE-11535
> URL: https://issues.apache.org/jira/browse/IGNITE-11535
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
[jira] [Created] (IGNITE-11537) SQL: enchanced log mode for SQL queries
Taras Ledkov created IGNITE-11537: - Summary: SQL: enchanced log mode for SQL queries Key: IGNITE-11537 URL: https://issues.apache.org/jira/browse/IGNITE-11537 Project: Ignite Issue Type: Task Reporter: Taras Ledkov Additional information about run queries are needed: - log each query start execution on H2 engine includes local queries and map parts of distributed query (needs to monitoring node SQL pressure); - EXPLAIN / ANALYZE for long running queries; - ResultSet cardinality for long running queries (e.g. by threshold); Enable / disable enhanced log mode may be managed by JMX, internal SQL command or other way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10799) Optimize affinity initialization/re-calculation
[
https://issues.apache.org/jira/browse/IGNITE-10799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791719#comment-16791719
]
Ignite TC Bot commented on IGNITE-10799:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3256705buildTypeId=IgniteTests24Java8_RunAll]
> Optimize affinity initialization/re-calculation
> ---
>
> Key: IGNITE-10799
> URL: https://issues.apache.org/jira/browse/IGNITE-10799
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In case of persistence enabled and a baseline is set we have 2 main
> approaches to recalculate affinity:
> {noformat}
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#onServerJoinWithExchangeMergeProtocol
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#onServerLeftWithExchangeMergeProtocol
> {noformat}
> Both of them following the same approach of recalculating:
> 1) Take a current baseline (ideal assignment).
> 2) Filter out offline nodes from it.
> 3) Choose new primary nodes if previous went away.
> 4) Place temporal primary nodes to late affinity assignment set.
> Looking at implementation details we may notice that we do a lot of
> unnecessary online nodes cache lookups and array list copies. The performance
> becomes too slow if we do recalculate affinity for replicated caches (It
> takes P * N on each node, where P - partitions count, N - the number of nodes
> in the cluster). In case of large partitions count or large cluster, it may
> take few seconds, which is unacceptable, because this process happens during
> PME and freezes ongoing cluster operations.
> We should investigate possible bottlenecks and improve the performance of
> affinity recalculation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11107) MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791697#comment-16791697
]
Ivan Pavlukhin edited comment on IGNITE-11107 at 3/13/19 1:39 PM:
--
Tests was adopted to run {{TRANSACTIONAL}} caches and fixed in IGNITE-11534 .
There are several ignored failures in MVCC run now. They should be fixed.
was (Author: pavlukhin):
Tests was adopted and fixed to pass on {{TRANSACTIONAL}} caches. There are
several ignored failures in MVCC run now. They should be fixed.
> MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
>
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Multiples tests in {{IgniteCachePartitionLossPolicySelfTest}} fail in forced
> MVCC mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791776#comment-16791776
]
Ilya Kasnacheev commented on IGNITE-10970:
--
Also maybe we should introduce an alias 'mvcc'?
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Priority: Minor
> Labels: usability
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11535) AtomicLong cannot be found after creation
[ https://issues.apache.org/jira/browse/IGNITE-11535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-11535: - Fix Version/s: 2.8 > AtomicLong cannot be found after creation > - > > Key: IGNITE-11535 > URL: https://issues.apache.org/jira/browse/IGNITE-11535 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10822) AbstractFreelist init reused page in wrong way.
[
https://issues.apache.org/jira/browse/IGNITE-10822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791724#comment-16791724
]
Andrew Mashenkov commented on IGNITE-10822:
---
Most likely test was fixed in some another ticket.
Mass test start within IGNITE-11215 PR looks ok.
> AbstractFreelist init reused page in wrong way.
> ---
>
> Key: IGNITE-10822
> URL: https://issues.apache.org/jira/browse/IGNITE-10822
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.8
>
>
> This is similar to IGNITE-9303.
> In IGNITE-9303 we missed wrong page flag check that hides this issue.
> After fixing page flag check, one of mvcc tests fails with assertion as
> Ignite can't lock page for write due to unknown reason: smth goes wrong with
> page tag.
> ExplicitWalDeltaConsistencyTest.testNotEmptyPds() fails in mvcc mode with
> next error
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:507)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetastorageRowStore.addRow(MetastorageRowStore.java:73)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.putData(MetaStorage.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:353)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.writeBaselineTopology(GridClusterStateProcessor.java:293)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForReadWrite(GridClusterStateProcessor.java:250)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForReadWrite(GridCacheDatabaseSharedManager.java:430)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.finishRecovery(GridCacheDatabaseSharedManager.java:884){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4003) Slow or faulty client can stall the whole cluster.
[
https://issues.apache.org/jira/browse/IGNITE-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791784#comment-16791784
]
Ilya Kasnacheev commented on IGNITE-4003:
-
[~briggxs] please elaborate your case on userlist. JIRA is not for
troubleshooting of particular deployments.
> Slow or faulty client can stall the whole cluster.
> --
>
> Key: IGNITE-4003
> URL: https://issues.apache.org/jira/browse/IGNITE-4003
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Ilya Lantukh
>Priority: Critical
>
> Steps to reproduce:
> 1) Start two server nodes and some data to cache.
> 2) Start a client from Docker subnet, which is not visible from the outside.
> Client will join the cluster.
> 3) Try to put something to cache or start another node to force rabalance.
> Cluster is stuck at this moment. Root cause - servers are constantly trying
> to establish outgoing connection to the client, but fail as Docker subnet is
> not visible from the outside. It may stop virtually all cluster operations.
> Typical thread dump:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to send message (node may
> have left the grid or TCP connection cannot be established due to firewall
> issues) [node=TcpDiscoveryNode [id=a15d74c2-1ec2-4349-9640-aeacd70d8714,
> addrs=[127.0.0.1, 172.17.0.6], sockAddrs=[/127.0.0.1:0, /127.0.0.1:0,
> /172.17.0.6:0], discPort=0, order=7241, intOrder=3707,
> lastExchangeTime=1474096941045, loc=false, ver=1.5.23#20160526-sha1:259146da,
> isClient=true], topic=T4 [topic=TOPIC_CACHE,
> id1=949732fd-1360-3a58-8d9e-0ff6ea6182cc,
> id2=a15d74c2-1ec2-4349-9640-aeacd70d8714, id3=2], msg=GridContinuousMessage
> [type=MSG_EVT_NOTIFICATION, routineId=7e13c48e-6933-48b2-9f15-8d92007930db,
> data=null, futId=null], policy=2]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1347)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1227)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1198)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1180)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:841)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:800)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:787)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3476)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:548)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:207)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.processForceKeyResponse(GridDhtPreloader.java:636)
> [ignite-core-1.5.23.jar:1.5.23]
> at
>
[jira] [Commented] (IGNITE-11482) MVCC: Error on TxLog initialization.
[
https://issues.apache.org/jira/browse/IGNITE-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791795#comment-16791795
]
Andrew Mashenkov commented on IGNITE-11482:
---
There is a race on txLog initialization during cache starts in parallel. See
GridCacheProcessor.prepareStartCaches().
> MVCC: Error on TxLog initialization.
>
>
> Key: IGNITE-11482
> URL: https://issues.apache.org/jira/browse/IGNITE-11482
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: mvcc_stability
> Fix For: 2.8
>
>
> Some [tests remained
> flaky|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-935846982857542309=TEST_STATUS_DESC=50_IgniteTests24Java8=__all_branches__]
> even after IGNITE-10582 has been fixed. It should be investigated again.
> {noformat}
> [21:44:14] (err) Failed to execute compound future reducer:
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false,
> cancelled=false, err=null, futs=TransformCollectionView [true, false, false,
> false]]class org.apache.ignite.IgniteCheckedException: Failed to complete
> exchange process.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3209)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3237)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3323)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3304)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1519)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:852)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2920)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2769)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize exchange locally [locNodeId=140a9253-f646-4691-9947-2b211a90]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1254)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:782)
> ... 4 more
> Caused by: java.lang.IllegalStateException: Failed to get page IO
> instance (page content is corrupted)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:85)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:97)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:181)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.reuse.ReuseListImpl.(ReuseListImpl.java:57)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog.init(TxLog.java:161)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog.(TxLog.java:87)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.ensureStarted(MvccProcessorImpl.java:302)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1552)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2325)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$null$6a5b31b9$1(GridCacheProcessor.java:2164)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCachesIfPossible$6(GridCacheProcessor.java:2104)
> at
>
[jira] [Commented] (IGNITE-11107) MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791697#comment-16791697
]
Ivan Pavlukhin commented on IGNITE-11107:
-
Tests was adopted and fixed to pass on {{TRANSACTIONAL}} caches. There are
several ignored failures in MVCC run now. They should be fixed.
> MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
>
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Multiples tests in {{IgniteCachePartitionLossPolicySelfTest}} fail in forced
> MVCC mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11215) MVCC: JVM crash in MVCC PDS 1 suite
[
https://issues.apache.org/jira/browse/IGNITE-11215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791696#comment-16791696
]
Andrew Mashenkov commented on IGNITE-11215:
---
I've fixed few potential races in mvcc Vacuum.
The root of the issue is PageMemoryTracker (it is used in test to verify WAL)
stopped too early.
> MVCC: JVM crash in MVCC PDS 1 suite
> ---
>
> Key: IGNITE-11215
> URL: https://issues.apache.org/jira/browse/IGNITE-11215
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: mvcc_stability
> Attachments: No_C2_opts_hs_err_pid957384.log, hs_err_pid429215.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes JVM crash
> [occurs|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_MvccPds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeHistoryList=failed]
> in {{vacuum-cleaner}} thread in {{ExplicitWalDeltaConsistencyTest}}.
> See attached crash report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2533460]]
* dll: CacheParityTest.TestCache - 0,0% fails in last 564 master runs.
{color:#d04437}Platform .NET{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2533459]]
* exe: CacheParityTest.TestCache - 0,0% fails in last 570 master runs.
* exe: PersistenceTest.TestWalDisableEnable - 0,0% fails in last 570 master
runs.
{color:#d04437}Cache (Full API){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2533433]]
* IgniteCacheFullApiSelfTestSuite:
GridCacheAtomicMultiNodeFullApiSelfTest.testIteratorLeakOnCancelCursor - 0,0%
fails in last 618 master runs.
* IgniteCacheFullApiSelfTestSuite:
GridCacheAtomicMultiNodeFullApiSelfTest.testIgniteCacheIterator - 0,0% fails in
last 618 master runs.
{color:#d04437}Hibernate 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2533388]]
* HibernateL2CacheTransactionalSelfTest.testRegionClear (last started)
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2533425]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2533472buildTypeId=IgniteTests24Java8_RunAll])
> Cache mode allows reads with consistency check and fix
> --
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Summary: Implement cache mode allows reads with consistency check and fix
(was: Cache mode allows reads with consistency check and fix)
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11535) AtomicLong cannot be found after creation
[
https://issues.apache.org/jira/browse/IGNITE-11535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-11535:
-
Description:
For now, IgniteAtomics use {{PartitionLossPolicy.IGNORE}}, which is the default
value for all caches, (see {{DataStructuresProcessor#cacheConfiguration}}).
Therefore, partition loss leads to the fact that information about IgniteAtomic
may be lost as well. In that case, any operation with IgniteAtomic results in
the following exception:
{code}
javax.cache.processor.EntryProcessorException: Failed to find atomic long:
atomicLong
{code}
{code:java}
Value: An error occurred while calling o2248.incrementAndGet.
: class org.apache.ignite.IgniteException: Failed to find atomic long:
nodeIdFilter_7
at
org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl.incrementAndGet(GridCacheAtomicLongImpl.java:105)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
at py4j.Gateway.invoke(Gateway.java:282)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.GatewayConnection.run(GatewayConnection.java:238)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.cache.processor.EntryProcessorException: Failed to find atomic
long: nodeIdFilter_7
at
org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:525)
at
org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:512)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:424)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1237)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:677)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1054)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:396)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:519)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
... 1 more
{code}
The bad news is that this IgniteAtomic cannot be removed or recreated on the
same node.
was:
For now, IgniteAtomics use {{PartitionLossPolicy.IGNORE}}, which is the default
value for all caches, (see {{DataStructuresProcessor#cacheConfiguration}}).
Therefore, partition loss leads to the fact that information about IgniteAtomic
may be lost as well. In that case, any operation with IgniteAtomic results in
the following exception:
{code:java}
Value: An error
[jira] [Updated] (IGNITE-11398) Remove leftover @RunWith(JUnit4.class)
[
https://issues.apache.org/jira/browse/IGNITE-11398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11398:
Labels: MakeTeamcityGreenAgain (was: )
> Remove leftover @RunWith(JUnit4.class)
> --
>
> Key: IGNITE-11398
> URL: https://issues.apache.org/jira/browse/IGNITE-11398
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During migration to junit4 transitional construction
> {{@RunWith(JUnit4.class)}} was used. And it was forgotten in couple of
> places. Let's clean up.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8574) Change Baseline auto-adjust parameters via JMX
[ https://issues.apache.org/jira/browse/IGNITE-8574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791837#comment-16791837 ] Dmitriy Govorukhin commented on IGNITE-8574: [~ibessonov] LGTM, thanks for the contribution, merged to master. > Change Baseline auto-adjust parameters via JMX > -- > > Key: IGNITE-8574 > URL: https://issues.apache.org/jira/browse/IGNITE-8574 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We would introduce at IGNITE-8571 new parameters. > We need to have option change them via JMX. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11538) SQL: Support new features (precision, scale, etc) in JDBC drivers
Pavel Kuznetsov created IGNITE-11538:
Summary: SQL: Support new features (precision, scale, etc) in JDBC
drivers
Key: IGNITE-11538
URL: https://issues.apache.org/jira/browse/IGNITE-11538
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Kuznetsov
Currently JDBC result set meta data return dummy value (0 or -1 depending on
the driver) for the precision and scale, but we already have all the info to
return correct values.
*Both thin and v2 driver are affected.*
See
{{org.apache.ignite.internal.jdbc2.JdbcResultSetMetadata#getPrecision}} - dummy 0
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryCursor#meta}} - thin
driver actually uses v1 version of the JdbcColumnMeta which returns -1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11384) Introduce an ability of services hot redeployment via DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-11384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791958#comment-16791958 ] Alexey Goncharuk commented on IGNITE-11384: --- [~daradurvs], I merged your changes to master. Please create a documentation ticket (should be linked to this) and resolve this one. > Introduce an ability of services hot redeployment via DeploymentSpi > --- > > Key: IGNITE-11384 > URL: https://issues.apache.org/jira/browse/IGNITE-11384 > Project: Ignite > Issue Type: Sub-task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > We can integrate service processor with DeploymentSpi to introduce an > opportunity of services hot redeployment. For this change, the service > processor should try to get and use registered classloader registered for the > service's class in DeploymentSpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11535) AtomicLong cannot be found after creation
[
https://issues.apache.org/jira/browse/IGNITE-11535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791822#comment-16791822
]
Ignite TC Bot commented on IGNITE-11535:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3305327]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3304201buildTypeId=IgniteTests24Java8_RunAll]
> AtomicLong cannot be found after creation
> -
>
> Key: IGNITE-11535
> URL: https://issues.apache.org/jira/browse/IGNITE-11535
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For now, IgniteAtomics use {{PartitionLossPolicy.IGNORE}}, which is the
> default value for all caches, (see
> {{DataStructuresProcessor#cacheConfiguration}}). Therefore, partition loss
> leads to the fact that information about IgniteAtomic may be lost as well. In
> that case, any operation with IgniteAtomic results in the following exception:
> {code}
> javax.cache.processor.EntryProcessorException: Failed to find atomic long:
> atomicLong
> {code}
> {code:java}
> Value: An error occurred while calling o2248.incrementAndGet.
> : class org.apache.ignite.IgniteException: Failed to find atomic long:
> nodeIdFilter_7
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl.incrementAndGet(GridCacheAtomicLongImpl.java:105)
> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
> at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
> at py4j.Gateway.invoke(Gateway.java:282)
> at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
> at py4j.commands.CallCommand.execute(CallCommand.java:79)
> at py4j.GatewayConnection.run(GatewayConnection.java:238)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.cache.processor.EntryProcessorException: Failed to find
> atomic long: nodeIdFilter_7
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:525)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:512)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:424)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1237)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:677)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1054)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:396)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:519)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
>
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791858#comment-16791858
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=- Run :: IntelliJ IDEA Inspections: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *- Run :: IntelliJ IDEA Inspections*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3305183buildTypeId=IgniteTests24Java8_RunIntelliJIdeaInspections]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10161) Be able to cancel any query by query id
[
https://issues.apache.org/jira/browse/IGNITE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791856#comment-16791856
]
Yury Gerzhedovich commented on IGNITE-10161:
[~vozerov], thanks for the review and comments.
# Fixed
# Added such test.
# Fixed.
Waiting a BOT vise.
> Be able to cancel any query by query id
> ---
>
> Key: IGNITE-10161
> URL: https://issues.apache.org/jira/browse/IGNITE-10161
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User should be able to cancel any query by query id through SQL command.
> SQL syntax: *KILL QUERY \{ASYNC} '<_query_id>'_*
> _ASYNC_ is optional parameter which return control immediately without
> waiting real cancellation will be done.
> By default, without ASYNC parameter, the request is blocking untill
> cancellation is not done.
> Query should be canceled together with its parts on all nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11538) SQL: Support new features (precision, scale, etc) in JDBC drivers
[
https://issues.apache.org/jira/browse/IGNITE-11538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-11538:
-
Description:
Currently JDBC result set meta data return dummy value (0) for the precision
and scale, but we already have all the info to return correct values.
*Both thin and v2 driver are affected.*
See
{{org.apache.ignite.internal.jdbc2.JdbcResultSetMetadata#getPrecision}} - dummy 0
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryCursor#meta}} - thin
driver actually uses v1 version of the JdbcColumnMeta;
{{org.apache.ignite.internal.jdbc.thin.JdbcThinResultSetMetadata#getPrecision}}
ignores precision and returns 0;
was:
Currently JDBC result set meta data return dummy value (0 or -1 depending on
the driver) for the precision and scale, but we already have all the info to
return correct values.
*Both thin and v2 driver are affected.*
See
{{org.apache.ignite.internal.jdbc2.JdbcResultSetMetadata#getPrecision}} - dummy 0
{{org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryCursor#meta}} - thin
driver actually uses v1 version of the JdbcColumnMeta which returns -1
> SQL: Support new features (precision, scale, etc) in JDBC drivers
> -
>
> Key: IGNITE-11538
> URL: https://issues.apache.org/jira/browse/IGNITE-11538
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> Currently JDBC result set meta data return dummy value (0) for the precision
> and scale, but we already have all the info to return correct values.
> *Both thin and v2 driver are affected.*
> See
> {{org.apache.ignite.internal.jdbc2.JdbcResultSetMetadata#getPrecision}} -
> dummy 0
> {{org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryCursor#meta}} -
> thin driver actually uses v1 version of the JdbcColumnMeta;
> {{org.apache.ignite.internal.jdbc.thin.JdbcThinResultSetMetadata#getPrecision}}
> ignores precision and returns 0;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792058#comment-16792058
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
9|https://ci.ignite.apache.org/viewLog.html?buildId=3306852]]
* exe: CacheParityTest.TestCache - 0,0% fails in last 364 master runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=3306855]]
* dll: CacheParityTest.TestCache - 0,0% fails in last 373 master runs.
{color:#d04437}Data Structures{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3306861]]
* IgniteCacheDataStructuresSelfTestSuite:
ExplicitTransactionalCacheConsistencyTest.test
{color:#d04437}_Javadoc_{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3306859]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3305204buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11539) Document services hot redeployment via DeploymentSpi
Vyacheslav Daradur created IGNITE-11539: --- Summary: Document services hot redeployment via DeploymentSpi Key: IGNITE-11539 URL: https://issues.apache.org/jira/browse/IGNITE-11539 Project: Ignite Issue Type: Task Components: documentation, managed services Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 It's necessary to document "how to use" service hot redeployment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11539) Document services hot redeployment via DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-11539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-11539: Labels: iep-17 (was: ) > Document services hot redeployment via DeploymentSpi > > > Key: IGNITE-11539 > URL: https://issues.apache.org/jira/browse/IGNITE-11539 > Project: Ignite > Issue Type: Task > Components: documentation, managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to document "how to use" service hot redeployment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[ https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792079#comment-16792079 ] Pavel Kuznetsov commented on IGNITE-11226: -- scheduled runall: https://ci.ignite.apache.org/viewQueued.html?itemId=3307606 > SQL: Remove GridQueryIndexing.prepareNativeStatement > > > Key: IGNITE-11226 > URL: https://issues.apache.org/jira/browse/IGNITE-11226 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Pavel Kuznetsov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This method is the only leak of H2 internals to the outer code. Close > analysis of code reveals that the only reason we have it is *JDBC metadata*. > Need to create a method which will prepare metadata for a statement and > return it as a detached object. Most probably we already have all necessary > mechanics. This is more about refactoring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11079) MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
[
https://issues.apache.org/jira/browse/IGNITE-11079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791417#comment-16791417
]
Roman Kondakov commented on IGNITE-11079:
-
[~amashenkov], tests are OK. Patch is ready for review.
> MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
> --
>
> Key: IGNITE-11079
> URL: https://issues.apache.org/jira/browse/IGNITE-11079
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See Tc run
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=925274886589214180=testDetails]
> Test fails after series of long JVM pauses with stacktrace:
> {code:java}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryBackupQueueTest.testManyQueryBackupQueue(IgniteCacheContinuousQueryBackupQueueTest.java:175)
> 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
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791418#comment-16791418
]
Ignite TC Bot commented on IGNITE-9165:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3294241buildTypeId=IgniteTests24Java8_RunAll]
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11233) Ignite Build for Java 11 does not reuse ignite-tools from Build Apache Ignite for some configurations, Compilation error
[
https://issues.apache.org/jira/browse/IGNITE-11233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791446#comment-16791446
]
Peter Ivanov commented on IGNITE-11233:
---
Double checked [Platform .NET
(NuGet)*|https://ci.ignite.apache.org/viewLog.html?buildId=3302317] build
configuration to be "green" in JDK11.
Guess ticket can be surely be resolved.
> Ignite Build for Java 11 does not reuse ignite-tools from Build Apache Ignite
> for some configurations, Compilation error
>
>
> Key: IGNITE-11233
> URL: https://issues.apache.org/jira/browse/IGNITE-11233
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> _Javadoc_ [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc=ignite-11213=buildTypeStatusDiv
> SPI (URI Deploy) [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SpiUriDeploy=ignite-11213=buildTypeStatusDiv
> RDD* [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Rdd=ignite-11213=buildTypeStatusDiv
> JCache TCK 1.1 [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JCacheTck11=ignite-11213=buildTypeStatusDiv
> Platform .NET (NuGet)* [ tests 0 Exit Code ]
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=3007897&_focus=904
> {noformat}
> [21:28:31][Step 1/1] [INFO] Compiling 9 source files to
> /data/teamcity/work/9198da4c51c3e112/modules/tools/target/classes
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:
>
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java
> uses or overrides a deprecated API that is marked for removal.
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:
> Recompile with -Xlint:removal for details.
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/classgen/ClassesGenerator.java:
>
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/classgen/ClassesGenerator.java
> uses unchecked or unsafe operations.
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/classgen/ClassesGenerator.java:
> Recompile with -Xlint:unchecked for details.
> [21:28:32][Step 1/1] [INFO]
> -
> [21:28:32][Step 1/1] [ERROR] COMPILATION ERROR :
> [21:28:32][Step 1/1] [INFO]
> -
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[21,29]
> package com.sun.tools.doclets does not exist
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[30,42]
> cannot find symbol
> [21:28:32][Step 1/1] symbol: class Taglet
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[37,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[44,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[51,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[58,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[65,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
>
