[jira] [Assigned] (IGNITE-9619) Document REST "getall" array format
[ https://issues.apache.org/jira/browse/IGNITE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-9619: --- Assignee: Denis Magda (was: Prachi Garg) > Document REST "getall" array format > --- > > Key: IGNITE-9619 > URL: https://issues.apache.org/jira/browse/IGNITE-9619 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ilya Kasnacheev >Assignee: Denis Magda >Priority: Minor > Labels: documentation > Fix For: 2.7 > > > https://apacheignite.readme.io/docs/rest-api#get-all <-- this page should > have a section about new IGNITE_REST_GETALL_AS_ARRAY System Property, as well > as an example of response after it is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9619) Document REST "getall" array format
[ https://issues.apache.org/jira/browse/IGNITE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-9619: --- Assignee: Prachi Garg (was: Denis Magda) > Document REST "getall" array format > --- > > Key: IGNITE-9619 > URL: https://issues.apache.org/jira/browse/IGNITE-9619 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ilya Kasnacheev >Assignee: Prachi Garg >Priority: Minor > Labels: documentation > Fix For: 2.7 > > > https://apacheignite.readme.io/docs/rest-api#get-all <-- this page should > have a section about new IGNITE_REST_GETALL_AS_ARRAY System Property, as well > as an example of response after it is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9619) Document REST "getall" array format
[ https://issues.apache.org/jira/browse/IGNITE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-9619: --- Assignee: Denis Magda (was: Prachi Garg) > Document REST "getall" array format > --- > > Key: IGNITE-9619 > URL: https://issues.apache.org/jira/browse/IGNITE-9619 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ilya Kasnacheev >Assignee: Denis Magda >Priority: Minor > Labels: documentation > Fix For: 2.7 > > > https://apacheignite.readme.io/docs/rest-api#get-all <-- this page should > have a section about new IGNITE_REST_GETALL_AS_ARRAY System Property, as well > as an example of response after it is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9619) Document REST "getall" array format
[ https://issues.apache.org/jira/browse/IGNITE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690384#comment-16690384 ] Prachi Garg commented on IGNITE-9619: - Added a callout at the end of the get all command section- https://apacheignite.readme.io/v2.6/docs/rest-api-27#section-get-all [~dmagda], please review. > Document REST "getall" array format > --- > > Key: IGNITE-9619 > URL: https://issues.apache.org/jira/browse/IGNITE-9619 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ilya Kasnacheev >Assignee: Prachi Garg >Priority: Minor > Labels: documentation > Fix For: 2.7 > > > https://apacheignite.readme.io/docs/rest-api#get-all <-- this page should > have a section about new IGNITE_REST_GETALL_AS_ARRAY System Property, as well > as an example of response after it is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690218#comment-16690218
]
Prachi Garg edited comment on IGNITE-9679 at 11/17/18 3:22 AM:
---
[~Artem Budnikov], looks good.
[~dmagda], please review.
was (Author: pgarg):
[~Artem Budnikov], looks good.
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> {{IgniteConfiguration.SystemWorkerBlockedTimeout}} configuration property
> affects monitoring behavior. At runtime monitoring settings can be changed
> via {{FailureHandlingMxBean}}.
> By default, liveness checks are enabled, but blocked system worker detection
> will not lead to failure handler invocation, see
> {{FailureProcessor#getDefaultFailureHandler}} .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg reassigned IGNITE-9679:
---
Assignee: Denis Magda (was: Prachi Garg)
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> {{IgniteConfiguration.SystemWorkerBlockedTimeout}} configuration property
> affects monitoring behavior. At runtime monitoring settings can be changed
> via {{FailureHandlingMxBean}}.
> By default, liveness checks are enabled, but blocked system worker detection
> will not lead to failure handler invocation, see
> {{FailureProcessor#getDefaultFailureHandler}} .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690218#comment-16690218
]
Prachi Garg commented on IGNITE-9679:
-
[~Artem Budnikov], looks good.
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> {{IgniteConfiguration.SystemWorkerBlockedTimeout}} configuration property
> affects monitoring behavior. At runtime monitoring settings can be changed
> via {{FailureHandlingMxBean}}.
> By default, liveness checks are enabled, but blocked system worker detection
> will not lead to failure handler invocation, see
> {{FailureProcessor#getDefaultFailureHandler}} .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9924) Rename "allow non-collacated joins" to allow distributed joins
[ https://issues.apache.org/jira/browse/IGNITE-9924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov resolved IGNITE-9924. --- Resolution: Duplicate > Rename "allow non-collacated joins" to allow distributed joins > -- > > Key: IGNITE-9924 > URL: https://issues.apache.org/jira/browse/IGNITE-9924 > Project: Ignite > Issue Type: Improvement > Components: visor >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Minor > Attachments: Screen Shot 2018-10-17 at 15.33.33.png > > > if you google "allow non-collacated joins" it will show you doc with title > about distributed join, our API use is/setDistributedJoins method, so why we > have this non-collacated in WebConsole, let's rename it to "allow distributed > joins" to make it more consistent to our API and doc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10312) Data streamer fails with CCE: o.a.i.i.util.future.GridFinishedFuture cannot be cast to o.a.i.i.p.cache.distributed.dht.GridDhtTopologyFuture
Sergey Kozlov created IGNITE-10312:
--
Summary: Data streamer fails with CCE:
o.a.i.i.util.future.GridFinishedFuture cannot be cast to
o.a.i.i.p.cache.distributed.dht.GridDhtTopologyFuture
Key: IGNITE-10312
URL: https://issues.apache.org/jira/browse/IGNITE-10312
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Sergey Kozlov
Use data streamer by client node fails:
{noformat}
[17:08:50] (err) Failed to execute compound future reducer: GridCompoundFuture
[rdc=null, initFlag=1, lsnrCalls=3, done=true, cancelled=false, err=class
o.a.i.IgniteCheckedException: DataStreamer request failed
[node=6423a8f7-3607-4192-bbf8-13f859e77abd], futs=[true, true, true,
true]]class org.apache.ignite.IgniteCheckedException: DataStreamer request
failed [node=6423a8f7-3607-4192-bbf8-13f859e77abd]
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1894)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
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)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassCastException:
org.apache.ignite.internal.util.future.GridFinishedFuture cannot be cast to
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFuture
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2051)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
... 6 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8379) Add maven-surefire-plugin support for PDS Compatibility tests
[
https://issues.apache.org/jira/browse/IGNITE-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689849#comment-16689849
]
Vyacheslav Daradur commented on IGNITE-8379:
Hi, [~vveider], I added support running tests from precompiled artifacts.
I've tested this locally, both {{mvn:tes}} and {{surefire:test}} works well on
source code and on precompiled artifacts.
Please, check if it works in a target environment.
> Add maven-surefire-plugin support for PDS Compatibility tests
> -
>
> Key: IGNITE-8379
> URL: https://issues.apache.org/jira/browse/IGNITE-8379
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> In continuation of the works on PDS Compatibility test suite, it is required
> to add support for {{maven-surefire-plugin}} in Compatibility Framework.
> See IGNITE-8275 for details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9798) Add TensorFlow Integration Page to Ignite website
[ https://issues.apache.org/jira/browse/IGNITE-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689797#comment-16689797 ] Akmal Chaudhri commented on IGNITE-9798: There are several pages available now on readme.io: https://dash.readme.io/project/apacheignite/v2.6/docs/tensor-flow https://dash.readme.io/project/apacheignite/v2.6/docs/ignite-dataset https://dash.readme.io/project/apacheignite/v2.6/docs/command-line-tool I have taken a pass at review and editing. > Add TensorFlow Integration Page to Ignite website > - > > Key: IGNITE-9798 > URL: https://issues.apache.org/jira/browse/IGNITE-9798 > Project: Ignite > Issue Type: Task > Components: documentation, site >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > We need to create a dedicated page for Ignite and TensorFlow integration. > Please put it under Machine Learning item of the Features menu. > [~abchaudhri], will provide a reference to the readme.io page with in-depth > integration description. > [~dmagda], I have discussed this with [~chief]. He will create a separate > section with new pages for TensorFlow Integration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9798) Add TensorFlow Integration Page to Ignite website
[ https://issues.apache.org/jira/browse/IGNITE-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689797#comment-16689797 ] Akmal Chaudhri edited comment on IGNITE-9798 at 11/16/18 6:20 PM: -- There are several pages available now on readme.io, created by [~chief]. [~pgarg], please review: https://dash.readme.io/project/apacheignite/v2.6/docs/tensor-flow https://dash.readme.io/project/apacheignite/v2.6/docs/ignite-dataset https://dash.readme.io/project/apacheignite/v2.6/docs/command-line-tool I have taken a pass at review and editing. was (Author: abchaudhri): There are several pages available now on readme.io: https://dash.readme.io/project/apacheignite/v2.6/docs/tensor-flow https://dash.readme.io/project/apacheignite/v2.6/docs/ignite-dataset https://dash.readme.io/project/apacheignite/v2.6/docs/command-line-tool I have taken a pass at review and editing. > Add TensorFlow Integration Page to Ignite website > - > > Key: IGNITE-9798 > URL: https://issues.apache.org/jira/browse/IGNITE-9798 > Project: Ignite > Issue Type: Task > Components: documentation, site >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > We need to create a dedicated page for Ignite and TensorFlow integration. > Please put it under Machine Learning item of the Features menu. > [~abchaudhri], will provide a reference to the readme.io page with in-depth > integration description. > [~dmagda], I have discussed this with [~chief]. He will create a separate > section with new pages for TensorFlow Integration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10311) SQL: Create system view with query co-location plans
[
https://issues.apache.org/jira/browse/IGNITE-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10311:
-
Labels: iep-24 (was: )
> SQL: Create system view with query co-location plans
>
>
> Key: IGNITE-10311
> URL: https://issues.apache.org/jira/browse/IGNITE-10311
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> It is very important to understand model of distributed execution for certain
> queries for performance tuning. Let's create a syhstem view which will
> iterate over cached two-step queries and print their plans in table form.
> Approximate structure (very raw):
> {code}
> CREATE VIEW sql_query_plan (
> plan_id, // Unique plan ID (node ID + unique local ID)
> sql, // Plain text
> sql_hash. // May be more convenient that query_id
> flags // Same query with different flags may result in different plans
> )
> CREATE VIEW sql_query_plan_fragments (
> plan_id, // Same plan ID
> order, // Together with plan_id it forms PK
> action, // What is this - "reduce", "skip reduce", "map", etc. (may be we
> will need multiple columns)
> sql, // SQL of the fragment (if applicable)
> )
> {code}
> Next user may list cached plans, select interesting, and query plan fragments
> view.
> We need to analyze other vendors to better understand what to show in views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10311) SQL: Create system view with query co-location plans
Vladimir Ozerov created IGNITE-10311:
Summary: SQL: Create system view with query co-location plans
Key: IGNITE-10311
URL: https://issues.apache.org/jira/browse/IGNITE-10311
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
It is very important to understand model of distributed execution for certain
queries for performance tuning. Let's create a syhstem view which will iterate
over cached two-step queries and print their plans in table form.
Approximate structure (very raw):
{code}
CREATE VIEW sql_query_plan (
plan_id, // Unique plan ID (node ID + unique local ID)
sql, // Plain text
sql_hash. // May be more convenient that query_id
flags // Same query with different flags may result in different plans
)
CREATE VIEW sql_query_plan_fragments (
plan_id, // Same plan ID
order, // Together with plan_id it forms PK
action, // What is this - "reduce", "skip reduce", "map", etc. (may be we
will need multiple columns)
sql, // SQL of the fragment (if applicable)
)
{code}
Next user may list cached plans, select interesting, and query plan fragments
view.
We need to analyze other vendors to better understand what to show in views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10309) SQL: Ability to specifiy affinity function equality during table creation
[
https://issues.apache.org/jira/browse/IGNITE-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10309:
-
Description:
Currently users may specify affinity key in {{CREATE TABLE}} command. However,
there are situations when custom affintiy function or custom affinity mapper
are used. In this case we do not know what actual fields are used for affinity
calculation, neither we know if two affinity functions are equal and produce
deterministic results *. In this case we may want to give user ability to
confirm on his own risk that certain caches has the same affinity functions and
are co-located.
To achieve this all we need is to add new string parameter, say,
{{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
function, we may compare their affinity functions keys. If they match, then we
may treat them co-located and extract partitions successfully.
\* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
{{FairAffinityFunction}} which depend on cluster history and may produce
different distributions between two caches even if two caches has the same
function parameters.
was:
Currently users may specify affinity key in {{CREATE TABLE}} command. However,
there are situations when custom affintiy function or custom affinity mapper
are used. In this case we do not know what actual fields are used for affinity
calculation, neither we know if two affinity functions are equal and produce
deterministic results *. In this case we may want to give user ability to
confirm on his own risk that certain caches has the same affinity functions and
are co-located.
To achieve this all we need is to add new string parameter, say,
{{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
function, we may compare their affinity functions keys. If they match, then we
may treat them co-located and extract partitions successfully.
* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
{{FairAffinityFunction}} which depend on cluster history and may produce
different distributions between two caches even if two caches has the same
function parameters.
> SQL: Ability to specifiy affinity function equality during table creation
> -
>
> Key: IGNITE-10309
> URL: https://issues.apache.org/jira/browse/IGNITE-10309
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> Currently users may specify affinity key in {{CREATE TABLE}} command.
> However, there are situations when custom affintiy function or custom
> affinity mapper are used. In this case we do not know what actual fields are
> used for affinity calculation, neither we know if two affinity functions are
> equal and produce deterministic results *. In this case we may want to give
> user ability to confirm on his own risk that certain caches has the same
> affinity functions and are co-located.
> To achieve this all we need is to add new string parameter, say,
> {{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
> function, we may compare their affinity functions keys. If they match, then
> we may treat them co-located and extract partitions successfully.
> \* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
> {{FairAffinityFunction}} which depend on cluster history and may produce
> different distributions between two caches even if two caches has the same
> function parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10310) SQL: Create TABLEs system view with affinity information
[ https://issues.apache.org/jira/browse/IGNITE-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10310: - Labels: iep-24 (was: ) > SQL: Create TABLEs system view with affinity information > > > Key: IGNITE-10310 > URL: https://issues.apache.org/jira/browse/IGNITE-10310 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Major > Labels: iep-24 > Fix For: 2.8 > > > Lets add a system view with our tables. At the very least it should include: > # table name > # cache name > # schema name > # affinity column > # affinity key (if IGNITE-10309 is implemented) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10310) SQL: Create TABLEs system view with affinity information
Vladimir Ozerov created IGNITE-10310: Summary: SQL: Create TABLEs system view with affinity information Key: IGNITE-10310 URL: https://issues.apache.org/jira/browse/IGNITE-10310 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Lets add a system view with our tables. At the very least it should include: # table name # cache name # schema name # affinity column # affinity key (if IGNITE-10309 is implemented) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10309) SQL: Ability to specifiy affinity function equality during table creation
[
https://issues.apache.org/jira/browse/IGNITE-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10309:
-
Labels: iep-24 (was: )
> SQL: Ability to specifiy affinity function equality during table creation
> -
>
> Key: IGNITE-10309
> URL: https://issues.apache.org/jira/browse/IGNITE-10309
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> Currently users may specify affinity key in {{CREATE TABLE}} command.
> However, there are situations when custom affintiy function or custom
> affinity mapper are used. In this case we do not know what actual fields are
> used for affinity calculation, neither we know if two affinity functions are
> equal and produce deterministic results *. In this case we may want to give
> user ability to confirm on his own risk that certain caches has the same
> affinity functions and are co-located.
> To achieve this all we need is to add new string parameter, say,
> {{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
> function, we may compare their affinity functions keys. If they match, then
> we may treat them co-located and extract partitions successfully.
> * Remember our {{RendezvousAffinityFunction}} which is stateless, and old
> {{FairAffinityFunction}} which depend on cluster history and may produce
> different distributions between two caches even if two caches has the same
> function parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10307) SQL: Extract partition info from JOINs
Vladimir Ozerov created IGNITE-10307:
Summary: SQL: Extract partition info from JOINs
Key: IGNITE-10307
URL: https://issues.apache.org/jira/browse/IGNITE-10307
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
Currently we do not extract partitions when JOINs are involved. Let's implement
it. We may start with relatively simple rules:
# No subqueries
# No GROUP BY
Then walk through JOINed tables and extract partitions from AND clauses.
There are some tricky things to consider:
# Resulting model (tree) must be craefted carefully so that we can reuse it
later in thin clients for efficient co-location.
# Resulting model may affect how we group tables during push-down phase.
Probably this would be huuuge thing, so may be it is better to implement it in
separate ticket
# When JOIN is performed partition info might be "transferred" between tables.
E.g.:
{code}
a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
{code}
In this case if tables are co-located (we may infer it automatically in some
cases), then {{a.id=:1}} partition rule can be "transferred" to
{{b.affinity_id=:1}}.
Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10309) SQL: Ability to specifiy affinity function equality during table creation
Vladimir Ozerov created IGNITE-10309:
Summary: SQL: Ability to specifiy affinity function equality
during table creation
Key: IGNITE-10309
URL: https://issues.apache.org/jira/browse/IGNITE-10309
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
Currently users may specify affinity key in {{CREATE TABLE}} command. However,
there are situations when custom affintiy function or custom affinity mapper
are used. In this case we do not know what actual fields are used for affinity
calculation, neither we know if two affinity functions are equal and produce
deterministic results *. In this case we may want to give user ability to
confirm on his own risk that certain caches has the same affinity functions and
are co-located.
To achieve this all we need is to add new string parameter, say,
{{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
function, we may compare their affinity functions keys. If they match, then we
may treat them co-located and extract partitions successfully.
* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
{{FairAffinityFunction}} which depend on cluster history and may produce
different distributions between two caches even if two caches has the same
function parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10308) SQL: Pass partition pruning models to JDBC thin driver
[ https://issues.apache.org/jira/browse/IGNITE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10308: - Labels: iep-24 (was: ) > SQL: Pass partition pruning models to JDBC thin driver > -- > > Key: IGNITE-10308 > URL: https://issues.apache.org/jira/browse/IGNITE-10308 > Project: Ignite > Issue Type: Task > Components: jdbc, sql >Reporter: Vladimir Ozerov >Priority: Major > Labels: iep-24 > Fix For: 2.8 > > > Once partitions are extracted from original query (IGNITE-10305), it might be > useful for thin clients: they could apply arguments locally and try to guess > the best node where to send the request. > Example: when there is only one partition, then it makes sense to send the > request directly to that node, so that only one hop is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10308) SQL: Pass partition pruning models to JDBC thin driver
Vladimir Ozerov created IGNITE-10308: Summary: SQL: Pass partition pruning models to JDBC thin driver Key: IGNITE-10308 URL: https://issues.apache.org/jira/browse/IGNITE-10308 Project: Ignite Issue Type: Task Components: jdbc, sql Reporter: Vladimir Ozerov Fix For: 2.8 Once partitions are extracted from original query (IGNITE-10305), it might be useful for thin clients: they could apply arguments locally and try to guess the best node where to send the request. Example: when there is only one partition, then it makes sense to send the request directly to that node, so that only one hop is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10307) SQL: Extract partition info from JOINs
[
https://issues.apache.org/jira/browse/IGNITE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10307:
-
Labels: iep-24 (was: )
> SQL: Extract partition info from JOINs
> --
>
> Key: IGNITE-10307
> URL: https://issues.apache.org/jira/browse/IGNITE-10307
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> Currently we do not extract partitions when JOINs are involved. Let's
> implement it. We may start with relatively simple rules:
> # No subqueries
> # No GROUP BY
> Then walk through JOINed tables and extract partitions from AND clauses.
> There are some tricky things to consider:
> # Resulting model (tree) must be craefted carefully so that we can reuse it
> later in thin clients for efficient co-location.
> # Resulting model may affect how we group tables during push-down phase.
> Probably this would be huuuge thing, so may be it is better to implement it
> in separate ticket
> # When JOIN is performed partition info might be "transferred" between
> tables. E.g.:
> {code}
> a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
> {code}
> In this case if tables are co-located (we may infer it automatically in some
> cases), then {{a.id=:1}} partition rule can be "transferred" to
> {{b.affinity_id=:1}}.
> Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
Vladimir Ozerov created IGNITE-10305:
Summary: SQL: Optimize query execution if it targets only one or
none partitions
Key: IGNITE-10305
URL: https://issues.apache.org/jira/browse/IGNITE-10305
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
This is a part of "Partition Pruning" IEP [1].
Currently we try to extract partitions from map queries and route requests
accordingly. Several problems with this approach:
1) Individual map queries may target the same partition, but we never know
that, so we may want to setup a merge table when it is not really needed.
2) Sometimes query may reduce to no partitions. In this case we should not
execute anything at all and simply return empty result set.
3) If the whole query targets only one partition, we may skip the whole
splitter phase!
I propose to do the following:
# Try to extract partition from "original" query.
# If we see that exactly one partition is involved, then original query is a
map query, and reduce should be performed in "skip merge table" mode
# If we see that there are no partitions because query is invalid (e.g. {{id =
1 AND id = 2}}), then stop and return no results. This decision should be
cached in two-step plan.
# If we see that there are some partitions, then we should apply arguments and
see the result. If result set is empty - return, but do not cache empty result
set decision, as it may change for another set of arguments.
# If none of above hold, then do pushdowns and split, and analyze partitions of
individual map queries. For those of them where partition set is empty, we
should return empty result set without executing anything.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10306) SQL: Transform subqueries to JOINs when possible
[ https://issues.apache.org/jira/browse/IGNITE-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10306: - Labels: iep-24 (was: ) > SQL: Transform subqueries to JOINs when possible > > > Key: IGNITE-10306 > URL: https://issues.apache.org/jira/browse/IGNITE-10306 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Major > Labels: iep-24 > Fix For: 2.8 > > > Currently subqueries are mostly not analyzed in any way. This makes our > distributed execution plan more complex to analyze and execute. Moreover, we > cannot extract partition information from such queries efficiently. We need > to apply the simplest "JOIN conversion" optimization on early query analysis > phase and try to transform our AST from subquery to join. > This should be done before partition extraction, pushdowns and splitter. See > [1] for more information. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10306) SQL: Transform subqueries to JOINs when possible
Vladimir Ozerov created IGNITE-10306: Summary: SQL: Transform subqueries to JOINs when possible Key: IGNITE-10306 URL: https://issues.apache.org/jira/browse/IGNITE-10306 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently subqueries are mostly not analyzed in any way. This makes our distributed execution plan more complex to analyze and execute. Moreover, we cannot extract partition information from such queries efficiently. We need to apply the simplest "JOIN conversion" optimization on early query analysis phase and try to transform our AST from subquery to join. This should be done before partition extraction, pushdowns and splitter. See [1] for more information. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
[
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10305:
-
Labels: iep-24 (was: )
> SQL: Optimize query execution if it targets only one or none partitions
> ---
>
> Key: IGNITE-10305
> URL: https://issues.apache.org/jira/browse/IGNITE-10305
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This is a part of "Partition Pruning" IEP [1].
> Currently we try to extract partitions from map queries and route requests
> accordingly. Several problems with this approach:
> 1) Individual map queries may target the same partition, but we never know
> that, so we may want to setup a merge table when it is not really needed.
> 2) Sometimes query may reduce to no partitions. In this case we should not
> execute anything at all and simply return empty result set.
> 3) If the whole query targets only one partition, we may skip the whole
> splitter phase!
> I propose to do the following:
> # Try to extract partition from "original" query.
> # If we see that exactly one partition is involved, then original query is a
> map query, and reduce should be performed in "skip merge table" mode
> # If we see that there are no partitions because query is invalid (e.g. {{id
> = 1 AND id = 2}}), then stop and return no results. This decision should be
> cached in two-step plan.
> # If we see that there are some partitions, then we should apply arguments
> and see the result. If result set is empty - return, but do not cache empty
> result set decision, as it may change for another set of arguments.
> # If none of above hold, then do pushdowns and split, and analyze partitions
> of individual map queries. For those of them where partition set is empty, we
> should return empty result set without executing anything.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown
[
https://issues.apache.org/jira/browse/IGNITE-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-5382.
-
Resolution: Won't Fix
> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: sql-performance
>
> We have thread-bound cached connection to H2 database which is bound to
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command,
> which is rather expensive and may cause slowdown when queries form different
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be
> careful with concurrency and resource leaks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5382) SQL: frequent switch between schemas cause severe slowdown
[
https://issues.apache.org/jira/browse/IGNITE-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689694#comment-16689694
]
Vladimir Ozerov commented on IGNITE-5382:
-
Slowdown is caused by calling {{SET SCHEMA}} SQL statement. This is not needed.
Instead, we may simply call {{Connection.setSchema()}} which does the same
avoiding expensive parsing and prepared statement execution. Will be fixed as a
part of IGNITE-10303.
> SQL: frequent switch between schemas cause severe slowdown
> --
>
> Key: IGNITE-5382
> URL: https://issues.apache.org/jira/browse/IGNITE-5382
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: sql-performance
>
> We have thread-bound cached connection to H2 database which is bound to
> specific schema. See {{IgniteH2Indexing.connectionForThread}}.
> When query with different schema is executed, we call {{SET SCHEMA}} command,
> which is rather expensive and may cause slowdown when queries form different
> caches are executed.
> To avoid this we should maintain thread-local map of such connections. Be
> careful with concurrency and resource leaks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10303) SQL: Move connection management logic into separate class
[
https://issues.apache.org/jira/browse/IGNITE-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689683#comment-16689683
]
Vladimir Ozerov commented on IGNITE-10303:
--
Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=2335351
> SQL: Move connection management logic into separate class
> -
>
> Key: IGNITE-10303
> URL: https://issues.apache.org/jira/browse/IGNITE-10303
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> Currently {{IgniteH2Indexing}} class is a mix of various mixed abstractions.
> One of them is connection management. Let's abstract it out.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10304) SQL: Encapsulate H2 query execution into ConnectionManager
Vladimir Ozerov created IGNITE-10304:
Summary: SQL: Encapsulate H2 query execution into ConnectionManager
Key: IGNITE-10304
URL: https://issues.apache.org/jira/browse/IGNITE-10304
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
This ticket should be done after IGNITE-10299. Currently {{ConnectionManager}}
exposes cached H2 connections to the outside. Sometimes these connections are
used in safe manner and {{ConnectionManager.onSqlException}} is called to
recycle bad connection. But most of the time this is not the case, what may
lead to unexpected behavior.
Let's try to hide all statement execution logic inside {{ConnectionManager}} to
avoid this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10303) SQL: Move connection management logic into separate class
[
https://issues.apache.org/jira/browse/IGNITE-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689676#comment-16689676
]
ASF GitHub Bot commented on IGNITE-10303:
-
GitHub user devozerov opened a pull request:
https://github.com/apache/ignite/pull/5418
IGNITE-10303
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10303
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5418.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5418
commit e6f47f8b032f6d18287b285fa153a18f8b018cc0
Author: devozerov
Date: 2018-11-16T15:32:09Z
Moved code. Dirty, but should work.
commit 19829ebb28c9f3eb9de23f1ee67fe054ad32a622
Author: devozerov
Date: 2018-11-16T15:50:18Z
Cleanup (1).
commit ab8502435b1670bd230a9befe92ac852ac131f8d
Author: devozerov
Date: 2018-11-16T16:19:12Z
WIP.
commit c06f23a4d23a383b97b91f66302752713541c777
Author: devozerov
Date: 2018-11-16T16:29:09Z
WIP.
commit fa5218f51e971b3b48eba682c110ac15abcbcd3f
Author: devozerov
Date: 2018-11-16T16:33:30Z
WIP (worked before this commit).
commit 7a7c038619842390269f06a9511fc85278806f5f
Author: devozerov
Date: 2018-11-16T16:38:17Z
Merged close routine.
commit 5b7ae7b56d52a101b3369791c13ee43dab0b2bec
Author: devozerov
Date: 2018-11-16T16:47:37Z
Dangerous: fixed schema change.
commit 35f475cbf6c7de42767b5f950f52229f9a8f37e7
Author: devozerov
Date: 2018-11-16T16:56:18Z
connectionForSchema -> connectionForThread
commit 2ae9003ad937b343588b30be31ee7dc835e2b60b
Author: devozerov
Date: 2018-11-16T17:07:08Z
Almost done.
commit ffddfd3a04925e3c8709ce2ff35596e0725b3ae2
Author: devozerov
Date: 2018-11-16T17:08:39Z
Done.
commit c1e7acc9c48de6f08bcbe2e5ff8252395300947d
Author: devozerov
Date: 2018-11-16T17:11:55Z
Rename.
> SQL: Move connection management logic into separate class
> -
>
> Key: IGNITE-10303
> URL: https://issues.apache.org/jira/browse/IGNITE-10303
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> Currently {{IgniteH2Indexing}} class is a mix of various mixed abstractions.
> One of them is connection management. Let's abstract it out.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10303) SQL: Move connection management logic into separate class
Vladimir Ozerov created IGNITE-10303:
Summary: SQL: Move connection management logic into separate class
Key: IGNITE-10303
URL: https://issues.apache.org/jira/browse/IGNITE-10303
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
Currently {{IgniteH2Indexing}} class is a mix of various mixed abstractions.
One of them is connection management. Let's abstract it out.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect hash code calculation
[ https://issues.apache.org/jira/browse/IGNITE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10290: -- Summary: Map.Entry interface for key cache may lead to incorrect hash code calculation (was: Map.Entry interface for key cache may lead to incorrect calculation hash code) > Map.Entry interface for key cache may lead to incorrect hash code calculation > - > > Key: IGNITE-10290 > URL: https://issues.apache.org/jira/browse/IGNITE-10290 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > Attachments: Reproducer.java > > > In case if use Map.Entry interface for a key, we can try to find (key, value) > in store with incorrect calculated hash code for binary representation, it > lead to result null. > The problem is in the > GridPartitionedSingleGetFuture#localGet() and > GridPartitionedGetFuture#localGet() does not execute prepareForCache before > reading cacheDataRow from row store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10177:
Description:
If needed, refer parent task for more details.
1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
steps, if there are any 4) remove redundant references to {{JUnit4.class}} if
there are any (like in {{@RunWith(JUnit4.class)}}) 5) in tests suite classes,
change {{extends TestSuite}} to either {{@RunWith(AllTests.class)}} or
{{@Suite.SuiteClasses}}
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
was:
If needed, refer parent task for more details.
1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
steps, if there are any 4) remove redundant references to {{JUnit4.class}} if
there are any (like in {{@RunWith(JUnit4.class)}}) 5) in tests suite classes,
change {{extends TestSuite}} to {{@RunWith(AllTests.class)}}
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> 1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
> dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
> steps, if there are any 4) remove redundant references to {{JUnit4.class}} if
> there are any (like in {{@RunWith(JUnit4.class)}}) 5) in tests suite classes,
> change {{extends TestSuite}} to either {{@RunWith(AllTests.class)}} or
> {{@Suite.SuiteClasses}}
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
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=16689619#comment-16689619
]
ASF GitHub Bot commented on IGNITE-4003:
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/5417
IGNITE-4003
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4003-2
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5417.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5417
commit 7d3aae218f69ef3959026463e97b4f6f2a836cf1
Author: Ilya Lantukh
Date: 2018-11-16T15:39:56Z
IGNITE-4003 : WIP.
commit c9667fbaf47f37cdffa48bb1c78eafb3550e4c55
Author: Ilya Lantukh
Date: 2018-11-16T16:17:43Z
IGNITE-4003 : Fixed recovery descriptor initialization.
> 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
>
[jira] [Commented] (IGNITE-10156) Invalid convertation DynamicCacheDescriptor to StoredCacheData
[ https://issues.apache.org/jira/browse/IGNITE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689617#comment-16689617 ] ASF GitHub Bot commented on IGNITE-10156: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5332 > Invalid convertation DynamicCacheDescriptor to StoredCacheData > -- > > Key: IGNITE-10156 > URL: https://issues.apache.org/jira/browse/IGNITE-10156 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Invalid convertation DynamicCacheDescriptor to StoredCacheData in > CacheRegistry#persistCacheConfigurations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10295) Rework Sending Full Message logging.
[ https://issues.apache.org/jira/browse/IGNITE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689596#comment-16689596 ] ASF GitHub Bot commented on IGNITE-10295: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5413 > Rework Sending Full Message logging. > > > Key: IGNITE-10295 > URL: https://issues.apache.org/jira/browse/IGNITE-10295 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message performed in 0 ms. > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message to all nodes performed in 0 ms. > [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] > Sending Single Message performed in 150 ms. > > For varying number of caches, server nodes or number of partitions, reported > single message time change respectively, but reported full message time > always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause > of async send of message. > The most we spend in this method is actually open connection on send() > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10295) Rework Sending Full Message logging.
[ https://issues.apache.org/jira/browse/IGNITE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10295: -- Ignite Flags: (was: Docs Required) > Rework Sending Full Message logging. > > > Key: IGNITE-10295 > URL: https://issues.apache.org/jira/browse/IGNITE-10295 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message performed in 0 ms. > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message to all nodes performed in 0 ms. > [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] > Sending Single Message performed in 150 ms. > > For varying number of caches, server nodes or number of partitions, reported > single message time change respectively, but reported full message time > always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause > of async send of message. > The most we spend in this method is actually open connection on send() > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10295) Rework Sending Full Message logging.
[ https://issues.apache.org/jira/browse/IGNITE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10295: -- Fix Version/s: 2.8 > Rework Sending Full Message logging. > > > Key: IGNITE-10295 > URL: https://issues.apache.org/jira/browse/IGNITE-10295 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message performed in 0 ms. > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message to all nodes performed in 0 ms. > [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] > Sending Single Message performed in 150 ms. > > For varying number of caches, server nodes or number of partitions, reported > single message time change respectively, but reported full message time > always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause > of async send of message. > The most we spend in this method is actually open connection on send() > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7017) Reconsider WAL archive strategy
[ https://issues.apache.org/jira/browse/IGNITE-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689588#comment-16689588 ] ASF GitHub Bot commented on IGNITE-7017: Github user dspavlov closed the pull request at: https://github.com/apache/ignite/pull/3200 > Reconsider WAL archive strategy > --- > > Key: IGNITE-7017 > URL: https://issues.apache.org/jira/browse/IGNITE-7017 > Project: Ignite > Issue Type: Task >Affects Versions: 2.3 >Reporter: Alexey Goncharuk >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.5 > > > Currently, we write WAL files in work directory and then copy them to the > archive after the segment is closed. > This was done to overcome XFS bug which leads to a double fsync cost > immediately after file creation. This approach leads to excessive disk usage > and can be optimized, especially for LOG_ONLY mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10302) MVCC: Update backups asynchronously
Roman Kondakov created IGNITE-10302: --- Summary: MVCC: Update backups asynchronously Key: IGNITE-10302 URL: https://issues.apache.org/jira/browse/IGNITE-10302 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Roman Kondakov Currently we update backups synchronously. It means we should wait all backup nodes apply transaction updates and send back acknowledgment for each statement before proceed. Actually, we do not have to wait until backups processed their updates. Instead we can update primary node, then "fire-and-forget" update to backups and continue handling next transaction statements. This approach eliminates waiting 2 extra network hops for each statement (sending update to backup and receiving ack back). Points to consider: * Backup should transit to "prepare" phase only when all updates were applied. * "Small" transactions can send updated values in prepare message. * "Big" transaction can stream batched updates to backups asynchronously. In this case we need to provide some backpressure implementation to prevent backup choke. * This optimization is applicable only for partitioned caches. This is because replicated caches may read data from backups and they should see their own updates -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10296) Change API of UpstreamTransformer to make it accept LearningEnvironment.
Artem Malykh created IGNITE-10296: - Summary: Change API of UpstreamTransformer to make it accept LearningEnvironment. Key: IGNITE-10296 URL: https://issues.apache.org/jira/browse/IGNITE-10296 Project: Ignite Issue Type: Improvement Components: ml Reporter: Artem Malykh Assignee: Artem Malykh For now UpstreamTransformer uses Random object as parameter to be able to fix it's behaviour through seeding. This goal should be reached by using random number generator from learning environment (IGNITE-10272). So, UpstreamTransformer should be result of work of UpstreamTransformerBuilder (LearningEnvironment -> UpstreamTransformer) or something like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689547#comment-16689547
]
Ignite TC Bot commented on IGNITE-10243:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Queries{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2316246]]
* IgniteCacheMvccSqlTestSuite:
IgniteCacheMvccSqlTestSuite$MvccColocatedTxPessimisticOriginatingNodeFailureRecoveryTest.testPrimaryNodeFailureCommit
- 0,0% fails in last 100 master runs.
{color:#d04437}IGFS (Linux and MacOS){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2316383]]
* IgniteIgfsLinuxAndMacOSTestSuite:
IgniteHadoopFileSystemShmemExternalToClientPrimarySelfTest.testDeleteSuccessfulIfPathIsOpenedToRead
- 0,0% fails in last 100 master runs.
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=2312122]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2312157buildTypeId=IgniteTests24Java8_RunAll]
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[ https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689551#comment-16689551 ] Dmitriy Pavlov commented on IGNITE-10243: - V20181116 > [TC Bot] Support partially cancelled suites in RunAll > - > > Key: IGNITE-10243 > URL: https://issues.apache.org/jira/browse/IGNITE-10243 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > For case, there is no TC run (RunAll) for the branch with normal status we > can check if there are any with canceled status. > If canceled status (unknown) appeared on the latest build in suite's rebuilds > sequence, we can use the latest build successful. > If there is only one build in rebuilds sequence and it was canceled => use > this one as a possible blocker for PR report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[ https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10243. - Resolution: Fixed > [TC Bot] Support partially cancelled suites in RunAll > - > > Key: IGNITE-10243 > URL: https://issues.apache.org/jira/browse/IGNITE-10243 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > For case, there is no TC run (RunAll) for the branch with normal status we > can check if there are any with canceled status. > If canceled status (unknown) appeared on the latest build in suite's rebuilds > sequence, we can use the latest build successful. > If there is only one build in rebuilds sequence and it was canceled => use > this one as a possible blocker for PR report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10234) ML: Create a skeleton for model inference in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689532#comment-16689532 ] ASF GitHub Bot commented on IGNITE-10234: - GitHub user dmitrievanthony opened a pull request: https://github.com/apache/ignite/pull/5415 IGNITE-10234: Inference workflow for ML You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10234 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5415.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5415 commit d9ea1918ec13533aaec70a0c3e36febecb426e27 Author: dmitrievanthony Date: 2018-11-16T14:59:49Z IGNITE-10234: First version of inference workflow implementation. > ML: Create a skeleton for model inference in Apache Ignite > -- > > Key: IGNITE-10234 > URL: https://issues.apache.org/jira/browse/IGNITE-10234 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > To support model inference in Apache Ignite for our models as well as for > loaded foreign models we need a common inference workflow. > This workflow should isolate model _inference/using_ from model _training_. > User should be able to: > * *Load/Unload any possible model (that can be represented as a function).* > _This part assumes that user specifies any underlying model, a bridge that > allows to interact with it and a signature of the model (accepted parameters, > returned value)._ > * *Access a list of loaded models.* > _Used should be able to access a list of loaded models, models that can be > used for inference without any additional manipulations. In terms of future > Cloud part it will be a table of models user can use in Web UI and start > using it._ > * *Start/Stop distributed infrastructure for inference utilizing cluster > resources.* > _Single inference is actually a single function call. We want to utilize all > cluster resources, so we need to replicate the model and start services that > are ready to use the model for inference on every node._ > * *Perform inference on top of the started infrastructure.* > _There are should be a gateway that allows to use a single entry point to > perform inference utilizing started on the previous step distributed service > infrastructure._ > _* Model in this task is assumed to be model with required preprocessing._ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10301) GridToStringBuilder is broken for classes with inheritance
[
https://issues.apache.org/jira/browse/IGNITE-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryabov Dmitrii reassigned IGNITE-10301:
---
Assignee: Ryabov Dmitrii
> GridToStringBuilder is broken for classes with inheritance
> --
>
> Key: IGNITE-10301
> URL: https://issues.apache.org/jira/browse/IGNITE-10301
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexey Goncharuk
>Assignee: Ryabov Dmitrii
>Priority: Blocker
> Fix For: 2.7
>
>
> Given the following class hierarchy
> {code}
> /** */
> private static class Parent {
> /** */
> private int a;
> /** {@inheritDoc} */
> @Override public String toString() {
> return S.toString(Parent.class, this);
> }
> }
> /** */
> private static class Child extends Parent {
> /** */
> private int b;
> /** {@inheritDoc} */
> @Override public String toString() {
> return S.toString(Child.class, this, super.toString());
> }
> }
> private static class Wrapper {
> /** */
> @GridToStringInclude
> Parent p = new Child();
> /** {@inheritDoc} */
> @Override public String toString() {
> return S.toString(Wrapper.class, this);
> }
> }
> {code}
> the next test fails:
> {code}
> /**
> */
> public void testHierarchy() {
> Wrapper w = new Wrapper();
> Parent p = w.p;
> String wS = w.toString();
> String pS = p.toString();
> // Expect wS to be "Wrapper [p=" + pS + ']'.
> assertEquals("Wrapper [p=" + pS + ']', wS);
> }
> {code}
> {code}
> Expected :Wrapper [p=Child [b=0, super=Parent [a=0]]]
> Actual :Wrapper [p=Parent [a=0]Child [b=0, super=]]
> {code}
> This is a regression from IGNITE-602. We need to fix this in 2.7 or revert
> IGNITE-602.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10172) Enabling cache statistics on a large cluster with a large number of caches can affect performance
[
https://issues.apache.org/jira/browse/IGNITE-10172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689535#comment-16689535
]
ASF GitHub Bot commented on IGNITE-10172:
-
GitHub user alex-plekhanov opened a pull request:
https://github.com/apache/ignite/pull/5416
IGNITE-10172 System flag introduced to disable discovery cache metrics
updates
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alex-plekhanov/ignite ignite-10172
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5416.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5416
commit 9fc84a2cb82286c2d73c4d905aab5e82a0d9604f
Author: Aleksey Plekhanov
Date: 2018-11-08T12:25:25Z
IGNITE-10172 System property to disable discovery cache metrics update
commit ea9a3992eade1f24c53ce541a22a7090c0519475
Author: Aleksey Plekhanov
Date: 2018-11-16T15:04:29Z
IGNITE-10172 Unit test
> Enabling cache statistics on a large cluster with a large number of caches
> can affect performance
> -
>
> Key: IGNITE-10172
> URL: https://issues.apache.org/jira/browse/IGNITE-10172
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In current implementation cache metrics are collected on each node and sent
> across whole cluster with discovery message
> ({{TcpDiscoveryMetricsUpdateMessage}}) with configured frequency
> ({{MetricsUpdateFrequency}}, 2 seconds by default).
> If there are a lot of caches and a lot of nodes in the cluster, metrics
> update message (which contain metrics for each cache on each node) can reach
> a critical size.
> Also frequently collecting all cache metrics have a negative performance
> impact.
> The only way now to disable cache metrics collecting and sending with
> discovery metrics update message is to disable statistics for each cache. But
> this also makes impossible to request some of cache metrics locally (for the
> current node only). Requesting a limited set of cache metrics on the current
> node doesn't have such performance impact as the frequent collecting of all
> cache metrics, but sometimes it's enough for diagnostic purposes.
> To solve this introduce new system property which will disable cache metrics
> sending with {{TcpDiscoveryMetricsUpdateMessage}} even if
> {{statisticsEnabled}} flag is true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10295) Rework Sending Full Message logging.
[ https://issues.apache.org/jira/browse/IGNITE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689529#comment-16689529 ] Sergey Antonov commented on IGNITE-10295: - Looks good for me. > Rework Sending Full Message logging. > > > Key: IGNITE-10295 > URL: https://issues.apache.org/jira/browse/IGNITE-10295 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message performed in 0 ms. > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message to all nodes performed in 0 ms. > [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] > Sending Single Message performed in 150 ms. > > For varying number of caches, server nodes or number of partitions, reported > single message time change respectively, but reported full message time > always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause > of async send of message. > The most we spend in this method is actually open connection on send() > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-10243:
---
Comment: was deleted
(was: {panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2])
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-10243:
---
Comment: was deleted
(was: {panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2])
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-10243:
---
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209639]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteClientReconnectCacheQueriesFailoverTest.testReconnectCacheQueries
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteErrorOnRebalanceTest.testErrorOnRebalance
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209591]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccContinuousWithTransformerReplicatedSelfTest.testContinuousWithTransformerAndRegularListenerKeepBinaryAsync
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209547]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync -
0,0% fails in last 100 master runs.
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2331419]]
* IgniteSpiTestSuite:
IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209538]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChangeFail
{color:#d04437}Start Nodes{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=2209571]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStopNodesFiltered - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartThreeNodesAndDoEmptyCall -
3,2% fails in last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartOneNode - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodes - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testCustomScript - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartFiveWithTwoSpecs - 3,2% fails
in last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered - 3,2% fails
in last 100 master runs.
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2209645buildTypeId=IgniteTests24Java8_RunAll])
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-10243:
---
Comment: was deleted
(was: {panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2])
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689508#comment-16689508
]
PetrovMikhail commented on IGNITE-10243:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2]
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689498#comment-16689498
]
PetrovMikhail commented on IGNITE-10243:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2]
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10301) GridToStringBuilder is broken for classes with inheritance
Alexey Goncharuk created IGNITE-10301:
-
Summary: GridToStringBuilder is broken for classes with inheritance
Key: IGNITE-10301
URL: https://issues.apache.org/jira/browse/IGNITE-10301
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexey Goncharuk
Fix For: 2.7
Given the following class hierarchy
{code}
/** */
private static class Parent {
/** */
private int a;
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(Parent.class, this);
}
}
/** */
private static class Child extends Parent {
/** */
private int b;
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(Child.class, this, super.toString());
}
}
private static class Wrapper {
/** */
@GridToStringInclude
Parent p = new Child();
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(Wrapper.class, this);
}
}
{code}
the next test fails:
{code}
/**
*/
public void testHierarchy() {
Wrapper w = new Wrapper();
Parent p = w.p;
String wS = w.toString();
String pS = p.toString();
// Expect wS to be "Wrapper [p=" + pS + ']'.
assertEquals("Wrapper [p=" + pS + ']', wS);
}
{code}
{code}
Expected :Wrapper [p=Child [b=0, super=Parent [a=0]]]
Actual :Wrapper [p=Parent [a=0]Child [b=0, super=]]
{code}
This is a regression from IGNITE-602. We need to fix this in 2.7 or revert
IGNITE-602.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10300) control.sh: incorrect error message after three tries on unsuccessful authorization
[
https://issues.apache.org/jira/browse/IGNITE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin reassigned IGNITE-10300:
---
Assignee: Pavel Voronkin
> control.sh: incorrect error message after three tries on unsuccessful
> authorization
> ---
>
> Key: IGNITE-10300
> URL: https://issues.apache.org/jira/browse/IGNITE-10300
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
>
> 1. start grid with securirty enabled
> 2. try to issue control.sh --cache
> authentication credentials asked
> 3. enter incorrect credentials three times
> expected: Authentication error printed and logged
> actual: Latest topology update failed error printed
> {noformat}
> IGNITE_HOME=`pwd` bin/control.sh --cache list .
> Control utility [ver. 2.5.1-p160#20181113-sha1:5f845ca7]
> 2018 Copyright(C) Apache Software Foundation
> User: mshonichev
>
> Authentication error, try connection again.
> user:
> password:
> Authentication error, try connection again.
> user:
> password:
> Authentication error, try connection again.
> user:
> password:
> Authentication error.
> Error: Latest topology update failed.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10300) control.sh: incorrect error message after three tries on unsuccessful authorization.
[
https://issues.apache.org/jira/browse/IGNITE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin updated IGNITE-10300:
Summary: control.sh: incorrect error message after three tries on
unsuccessful authorization. (was: control.sh: incorrect error message after
three tries on unsuccessful authorization)
> control.sh: incorrect error message after three tries on unsuccessful
> authorization.
>
>
> Key: IGNITE-10300
> URL: https://issues.apache.org/jira/browse/IGNITE-10300
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
>
> 1. start grid with securirty enabled
> 2. try to issue control.sh --cache
> authentication credentials asked
> 3. enter incorrect credentials three times
> expected: Authentication error printed and logged
> actual: Latest topology update failed error printed
> {noformat}
> IGNITE_HOME=`pwd` bin/control.sh --cache list .
> Control utility [ver. 2.5.1-p160#20181113-sha1:5f845ca7]
> 2018 Copyright(C) Apache Software Foundation
> User: mshonichev
>
> Authentication error, try connection again.
> user:
> password:
> Authentication error, try connection again.
> user:
> password:
> Authentication error, try connection again.
> user:
> password:
> Authentication error.
> Error: Latest topology update failed.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
[ https://issues.apache.org/jira/browse/IGNITE-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689501#comment-16689501 ] Vladimir Ozerov commented on IGNITE-10299: -- Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=2333920 > SQL: Extract SELECT and DML plan caches into single class > - > > Key: IGNITE-10299 > URL: https://issues.apache.org/jira/browse/IGNITE-10299 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > > In future we will need to merge plans for both DML and SELECTs (both local > and distributed) into a single entity. This ticket is the first part of this > effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10298) Possible deadlock between restore partition states and checkpoint begin
Pavel Kovalenko created IGNITE-10298:
Summary: Possible deadlock between restore partition states and
checkpoint begin
Key: IGNITE-10298
URL: https://issues.apache.org/jira/browse/IGNITE-10298
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Fix For: 2.8
There is possible deadlock between "restorePartitionStates" phase during caches
starting and currently running checkpointer:
{noformat}
"db-checkpoint-thread-#50" #89 prio=5 os_prio=0 tid=0x1ad57800
nid=0x2b58 waiting on condition [0x7e42e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xddabfcc8> (a
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at
org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7515)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1331)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.fullSize(GridCacheOffheapManager.java:1459)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3397)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3009)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2934)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
"exchange-worker-#42" #69 prio=5 os_prio=0 tid=0x1c1cd800 nid=0x259c
waiting on condition [0x249ae000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x80b634a0> (a
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1328)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1212)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.initialUpdateCounter(GridCacheOffheapManager.java:1537)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.onPartitionInitialCounterUpdated(GridCacheOffheapManager.java:633)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2365)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1174)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1119)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:703)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Possible solution is performing
[jira] [Commented] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
[ https://issues.apache.org/jira/browse/IGNITE-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689491#comment-16689491 ] ASF GitHub Bot commented on IGNITE-10299: - GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5414 IGNITE-10299 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10299 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5414.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5414 commit 68145c6eb0de4e4254a5804deb1b84f9a0a3be41 Author: devozerov Date: 2018-11-16T14:16:11Z DML. commit 0ab81dd184922eabb362a19c80757f67ea7763c3 Author: devozerov Date: 2018-11-16T14:24:54Z SQL. commit 02fe236eb1005ab9b7e0164bff9570c6b8612990 Author: devozerov Date: 2018-11-16T14:28:53Z Renames. commit 5f0dac97ca315aade75171bdd4d60932208106ca Author: devozerov Date: 2018-11-16T14:31:46Z WIP. commit b3ea9113de81a6d97d2a5acdf8881c966d186f3c Author: devozerov Date: 2018-11-16T14:35:48Z Minors. > SQL: Extract SELECT and DML plan caches into single class > - > > Key: IGNITE-10299 > URL: https://issues.apache.org/jira/browse/IGNITE-10299 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > > In future we will need to merge plans for both DML and SELECTs (both local > and distributed) into a single entity. This ticket is the first part of this > effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10300) control.sh: incorrect error message after three tries on unsuccessful authorization
Pavel Voronkin created IGNITE-10300:
---
Summary: control.sh: incorrect error message after three tries on
unsuccessful authorization
Key: IGNITE-10300
URL: https://issues.apache.org/jira/browse/IGNITE-10300
Project: Ignite
Issue Type: Bug
Reporter: Pavel Voronkin
1. start grid with securirty enabled
2. try to issue control.sh --cache
authentication credentials asked
3. enter incorrect credentials three times
expected: Authentication error printed and logged
actual: Latest topology update failed error printed
{noformat}
IGNITE_HOME=`pwd` bin/control.sh --cache list .
Control utility [ver. 2.5.1-p160#20181113-sha1:5f845ca7]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Authentication error, try connection again.
user:
password:
Authentication error, try connection again.
user:
password:
Authentication error, try connection again.
user:
password:
Authentication error.
Error: Latest topology update failed.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689488#comment-16689488
]
PetrovMikhail commented on IGNITE-10243:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2]
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
Vladimir Ozerov created IGNITE-10299: Summary: SQL: Extract SELECT and DML plan caches into single class Key: IGNITE-10299 URL: https://issues.apache.org/jira/browse/IGNITE-10299 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 In future we will need to merge plans for both DML and SELECTs (both local and distributed) into a single entity. This ticket is the first part of this effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node
[ https://issues.apache.org/jira/browse/IGNITE-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689494#comment-16689494 ] Aliaksandr Kazlou commented on IGNITE-3373: --- Hi, [~DmitriyGovorukhin]. Sorry for the delay. I do remember about the request, and have this in my TODO list. Right now we prepare for the major event for the product we build, it will be done next Wednesday, then would have more free time to look into further and share the details with you. > Distributed IgniteSet shows size() == 0 for any new node > > > Key: IGNITE-3373 > URL: https://issues.apache.org/jira/browse/IGNITE-3373 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Velichko >Assignee: Dmitriy Govorukhin >Priority: Major > Attachments: DistributedSetDemo.java > > > For distributed IgniteSet new node shows incorrect size igniteSet.size() == > 0, but igniteSet.contains(42L) == true -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10295) Rework Sending Full Message logging.
[ https://issues.apache.org/jira/browse/IGNITE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689482#comment-16689482 ] ASF GitHub Bot commented on IGNITE-10295: - GitHub user voropava opened a pull request: https://github.com/apache/ignite/pull/5413 IGNITE-10295 Added info logging for long connection establish methods… …, removed useless logging of Sending Full Message. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10295 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5413.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5413 commit da856f3883c76276eb034cfbea70a7beb85ea8d8 Author: Pavel Voronkin Date: 2018-11-09T12:00:03Z IGNITE-10295 Added info logging for long connection establish methods, removed useless logging of Sending Full Message. > Rework Sending Full Message logging. > > > Key: IGNITE-10295 > URL: https://issues.apache.org/jira/browse/IGNITE-10295 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message performed in 0 ms. > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message to all nodes performed in 0 ms. > [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] > Sending Single Message performed in 150 ms. > > For varying number of caches, server nodes or number of partitions, reported > single message time change respectively, but reported full message time > always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause > of async send of message. > The most we spend in this method is actually open connection on send() > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[
https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689484#comment-16689484
]
PetrovMikhail commented on IGNITE-10243:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209639]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteClientReconnectCacheQueriesFailoverTest.testReconnectCacheQueries
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteErrorOnRebalanceTest.testErrorOnRebalance
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209591]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccContinuousWithTransformerReplicatedSelfTest.testContinuousWithTransformerAndRegularListenerKeepBinaryAsync
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209547]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync -
0,0% fails in last 100 master runs.
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2331419]]
* IgniteSpiTestSuite:
IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209538]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChangeFail
{color:#d04437}Start Nodes{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=2209571]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStopNodesFiltered - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartThreeNodesAndDoEmptyCall -
3,2% fails in last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartOneNode - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodes - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testCustomScript - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartFiveWithTwoSpecs - 3,2% fails
in last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered - 3,2% fails
in last 100 master runs.
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2209645buildTypeId=IgniteTests24Java8_RunAll]
> [TC Bot] Support partially cancelled suites in RunAll
> -
>
> Key: IGNITE-10243
> URL: https://issues.apache.org/jira/browse/IGNITE-10243
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> For case, there is no TC run (RunAll) for the branch with normal status we
> can check if there are any with canceled status.
> If canceled status (unknown) appeared on the latest build in suite's rebuilds
> sequence, we can use the latest build successful.
> If there is only one build in rebuilds sequence and it was canceled => use
> this one as a possible blocker for PR report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10002) MVCC: Create "Cache 2" test suite for MVCC mode.
[
https://issues.apache.org/jira/browse/IGNITE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689481#comment-16689481
]
Ignite TC Bot commented on IGNITE-10002:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2326389]]
* ZookeeperDiscoverySpiTestSuite4:
IgniteCachePutRetryAtomicSelfTest.testPutAsyncStoreEnabled - 0,0% fails in last
100 master runs.
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2326376]]
* exe: PersistenceTest.TestWalDisableEnable - 0,0% fails in last 100 master
runs.
{color:#d04437}PDS (Compatibility)*{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2326366]]
* IgniteCompatibilityBasicTestSuite:
PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_3
- 0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2326390buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Create "Cache 2" test suite for MVCC mode.
>
>
> Key: IGNITE-10002
> URL: https://issues.apache.org/jira/browse/IGNITE-10002
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Create MVCC version of IgniteCacheTestSuite2 and add it to TC.
> All non-relevant tests should be marked as ignored.
> Failed tests should be muted and tickets should be created for unknown
> failure reasons.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10297) Investigate possibility of restricting API of Upstream transformer
[ https://issues.apache.org/jira/browse/IGNITE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689467#comment-16689467 ] Anton Dmitriev commented on IGNITE-10297: - Could we also consider in this task an ability to avoid using of additional _TransformerChain_ and just use _andThen_ approach? > Investigate possibility of restricting API of Upstream transformer > -- > > Key: IGNITE-10297 > URL: https://issues.apache.org/jira/browse/IGNITE-10297 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > > Signature of 'transform' method of UpstreamTransformer is > Stream -> Stream. For now it is used only for > bagging and for that purpose, UpstreamEntry -> Stream would > suffice (just use 'flatMap' on upstream), maybe we should change signature to > this form. From other hand, we'll cut some possibilities like limiting of > upstream. This question needs investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10260) MVCC: GetAndPutIfAbsent operation return no result.
[ https://issues.apache.org/jira/browse/IGNITE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689479#comment-16689479 ] ASF GitHub Bot commented on IGNITE-10260: - GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5412 IGNITE-10260: MVCC: GetAndPutIfAbsent operation return no result. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10260 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5412.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5412 commit 4053db079dffe1352b3df93e93020c028eff43be Author: Andrey V. Mashenkov Date: 2018-11-16T14:27:56Z IGNITE-10260: Fix getAndPutIfAbsent. > MVCC: GetAndPutIfAbsent operation return no result. > --- > > Key: IGNITE-10260 > URL: https://issues.apache.org/jira/browse/IGNITE-10260 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > Next test (but may be not the only) are failed with Mvcc cache mode: > CachePutIfAbsentTest.testTxConflictGetAndPutIfAbsent() > CacheEnumOperationsSingleNodeTest.testMvccTx() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10296) Change API of UpstreamTransformer to make it accept LearningEnvironment.
[ https://issues.apache.org/jira/browse/IGNITE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10296: Fix Version/s: 2.8 > Change API of UpstreamTransformer to make it accept LearningEnvironment. > > > Key: IGNITE-10296 > URL: https://issues.apache.org/jira/browse/IGNITE-10296 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > For now UpstreamTransformer uses Random object as parameter to be able to fix > it's behaviour through seeding. This goal should be reached by using random > number generator from learning environment (IGNITE-10272). So, > UpstreamTransformer should be result of work of UpstreamTransformerBuilder > (LearningEnvironment -> UpstreamTransformer) or something like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10296) Change API of UpstreamTransformer to make it accept LearningEnvironment.
[ https://issues.apache.org/jira/browse/IGNITE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10296: Ignite Flags: (was: Docs Required) > Change API of UpstreamTransformer to make it accept LearningEnvironment. > > > Key: IGNITE-10296 > URL: https://issues.apache.org/jira/browse/IGNITE-10296 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > For now UpstreamTransformer uses Random object as parameter to be able to fix > it's behaviour through seeding. This goal should be reached by using random > number generator from learning environment (IGNITE-10272). So, > UpstreamTransformer should be result of work of UpstreamTransformerBuilder > (LearningEnvironment -> UpstreamTransformer) or something like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10296) Change API of UpstreamTransformer to make it accept LearningEnvironment.
[ https://issues.apache.org/jira/browse/IGNITE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10296: Affects Version/s: 2.8 > Change API of UpstreamTransformer to make it accept LearningEnvironment. > > > Key: IGNITE-10296 > URL: https://issues.apache.org/jira/browse/IGNITE-10296 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > For now UpstreamTransformer uses Random object as parameter to be able to fix > it's behaviour through seeding. This goal should be reached by using random > number generator from learning environment (IGNITE-10272). So, > UpstreamTransformer should be result of work of UpstreamTransformerBuilder > (LearningEnvironment -> UpstreamTransformer) or something like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10297) Investigate possibility of restricting API of Upstream transformer
[ https://issues.apache.org/jira/browse/IGNITE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10297: Ignite Flags: (was: Docs Required) > Investigate possibility of restricting API of Upstream transformer > -- > > Key: IGNITE-10297 > URL: https://issues.apache.org/jira/browse/IGNITE-10297 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > Signature of 'transform' method of UpstreamTransformer is > Stream -> Stream. For now it is used only for > bagging and for that purpose, UpstreamEntry -> Stream would > suffice (just use 'flatMap' on upstream), maybe we should change signature to > this form. From other hand, we'll cut some possibilities like limiting of > upstream. This question needs investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10297) Investigate possibility of restricting API of Upstream transformer
[ https://issues.apache.org/jira/browse/IGNITE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10297: Affects Version/s: 2.8 > Investigate possibility of restricting API of Upstream transformer > -- > > Key: IGNITE-10297 > URL: https://issues.apache.org/jira/browse/IGNITE-10297 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > Signature of 'transform' method of UpstreamTransformer is > Stream -> Stream. For now it is used only for > bagging and for that purpose, UpstreamEntry -> Stream would > suffice (just use 'flatMap' on upstream), maybe we should change signature to > this form. From other hand, we'll cut some possibilities like limiting of > upstream. This question needs investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10297) Investigate possibility of restricting API of Upstream transformer
[ https://issues.apache.org/jira/browse/IGNITE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10297: Fix Version/s: 2.8 > Investigate possibility of restricting API of Upstream transformer > -- > > Key: IGNITE-10297 > URL: https://issues.apache.org/jira/browse/IGNITE-10297 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > Signature of 'transform' method of UpstreamTransformer is > Stream -> Stream. For now it is used only for > bagging and for that purpose, UpstreamEntry -> Stream would > suffice (just use 'flatMap' on upstream), maybe we should change signature to > this form. From other hand, we'll cut some possibilities like limiting of > upstream. This question needs investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10177:
Description:
If needed, refer parent task for more details.
1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
steps, if there are any 4) remove redundant references to {{JUnit4.class}} if
there are any (like in {{@RunWith(JUnit4.class)}}) 5) in tests suite classes,
change {{extends TestSuite}} to {{@RunWith(AllTests.class)}}
was:
If needed, refer parent task for more details.
1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
steps, if there are any 4) remove redundant references to {{JUnit4.class}} if
there are any (like in {{\@RunWith(JUnit4.class)}})
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> 1) remove deprecated API of GridAbstractTest and its subclasses 2) remove
> dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior
> steps, if there are any 4) remove redundant references to {{JUnit4.class}} if
> there are any (like in {{@RunWith(JUnit4.class)}}) 5) in tests suite classes,
> change {{extends TestSuite}} to {{@RunWith(AllTests.class)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10297) Investigate possibility of restricting API of Upstream transformer
Artem Malykh created IGNITE-10297: - Summary: Investigate possibility of restricting API of Upstream transformer Key: IGNITE-10297 URL: https://issues.apache.org/jira/browse/IGNITE-10297 Project: Ignite Issue Type: Improvement Components: ml Reporter: Artem Malykh Assignee: Artem Malykh Signature of 'transform' method of UpstreamTransformer is Stream -> Stream. For now it is used only for bagging and for that purpose, UpstreamEntry -> Stream would suffice (just use 'flatMap' on upstream), maybe we should change signature to this form. From other hand, we'll cut some possibilities like limiting of upstream. This question needs investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9355) Document new system views (nodes, node attributes, baseline nodes, node metrics)
[
https://issues.apache.org/jira/browse/IGNITE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689418#comment-16689418
]
Artem Budnikov commented on IGNITE-9355:
[~dmagda]
Agree. I already created the "Management and Monitoring" section and moved the
two pages there.
> Document new system views (nodes, node attributes, baseline nodes, node
> metrics)
>
>
> Key: IGNITE-9355
> URL: https://issues.apache.org/jira/browse/IGNITE-9355
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document three new SQL system views.
> # Explain users that new system SQL schema appeared, named "IGNITE", where
> all views are stored
> # System view NODES - list of current nodes in topology. Columns: ID,
> CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER,
> ADDRESSES, HOSTNAMES
> # System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID,
> NAME, VALUE
> # System view BASELINE_NODES - list of baseline topology nodes. Columns:
> CONSISTENT_ID, ONLINE (whether node is up and running at the moment)
> # System view NODE_METRICS - node metrics. Columns - see
> \{{org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewNodeMetrics}}
> class
> # Explain limitations: views cannot be joined with user tables; it is not
> allowed to create other objects (tables, indexes) in "IGNITE" schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10243) [TC Bot] Support partially cancelled suites in RunAll
[ https://issues.apache.org/jira/browse/IGNITE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689417#comment-16689417 ] ASF GitHub Bot commented on IGNITE-10243: - asfgit closed pull request #69: IGNITE-10243 Chain analysis entry points are get now from preloaded b… URL: https://github.com/apache/ignite-teamcity-bot/pull/69 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [TC Bot] Support partially cancelled suites in RunAll > - > > Key: IGNITE-10243 > URL: https://issues.apache.org/jira/browse/IGNITE-10243 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > For case, there is no TC run (RunAll) for the branch with normal status we > can check if there are any with canceled status. > If canceled status (unknown) appeared on the latest build in suite's rebuilds > sequence, we can use the latest build successful. > If there is only one build in rebuilds sequence and it was canceled => use > this one as a possible blocker for PR report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10295) Rework Sending Full Message logging.
[ https://issues.apache.org/jira/browse/IGNITE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10295: Description: [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full Message performed in 0 ms. [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full Message to all nodes performed in 0 ms. [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] Sending Single Message performed in 150 ms. For varying number of caches, server nodes or number of partitions, reported single message time change respectively, but reported full message time always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause of async send of message. The most we spend in this method is actually open connection on send() > Rework Sending Full Message logging. > > > Key: IGNITE-10295 > URL: https://issues.apache.org/jira/browse/IGNITE-10295 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Priority: Major > > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message performed in 0 ms. > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message to all nodes performed in 0 ms. > [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] > Sending Single Message performed in 150 ms. > > For varying number of caches, server nodes or number of partitions, reported > single message time change respectively, but reported full message time > always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause > of async send of message. > The most we spend in this method is actually open connection on send() > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10295) Rework Sending Full Message logging.
[ https://issues.apache.org/jira/browse/IGNITE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin reassigned IGNITE-10295: --- Assignee: Pavel Voronkin > Rework Sending Full Message logging. > > > Key: IGNITE-10295 > URL: https://issues.apache.org/jira/browse/IGNITE-10295 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message performed in 0 ms. > [16:33:34,410][INFO][sys-#122][GridDhtPartitionsExchangeFuture] Sending Full > Message to all nodes performed in 0 ms. > [16:33:32,993][INFO][exchange-worker-#66][GridDhtPartitionsExchangeFuture] > Sending Single Message performed in 150 ms. > > For varying number of caches, server nodes or number of partitions, reported > single message time change respectively, but reported full message time > always printed as 0 or 1 ms. Seems that it is calculated incorrectly, cause > of async send of message. > The most we spend in this method is actually open connection on send() > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3373) Distributed IgniteSet shows size() == 0 for any new node
[ https://issues.apache.org/jira/browse/IGNITE-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689410#comment-16689410 ] Dmitriy Govorukhin commented on IGNITE-3373: [~akazlou] Do you have updates? > Distributed IgniteSet shows size() == 0 for any new node > > > Key: IGNITE-3373 > URL: https://issues.apache.org/jira/browse/IGNITE-3373 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Velichko >Assignee: Dmitriy Govorukhin >Priority: Major > Attachments: DistributedSetDemo.java > > > For distributed IgniteSet new node shows incorrect size igniteSet.size() == > 0, but igniteSet.contains(42L) == true -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10295) Rework Sending Full Message logging.
Pavel Voronkin created IGNITE-10295: --- Summary: Rework Sending Full Message logging. Key: IGNITE-10295 URL: https://issues.apache.org/jira/browse/IGNITE-10295 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8379) Add maven-surefire-plugin support for PDS Compatibility tests
[
https://issues.apache.org/jira/browse/IGNITE-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689401#comment-16689401
]
ASF GitHub Bot commented on IGNITE-8379:
GitHub user daradurvs opened a pull request:
https://github.com/apache/ignite/pull/5411
IGNITE-8379 Add maven-surefire-plugin support for PDS Compatibility tests
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/daradurvs/ignite ignite-8379
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5411.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5411
commit fb00b524aebfe4a48dc39ad98d6fb7aa245cf1c1
Author: Vyacheslav Daradur
Date: 2018-11-16T13:07:55Z
Introduced support precompilled artifacts; refactoring
> Add maven-surefire-plugin support for PDS Compatibility tests
> -
>
> Key: IGNITE-8379
> URL: https://issues.apache.org/jira/browse/IGNITE-8379
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> In continuation of the works on PDS Compatibility test suite, it is required
> to add support for {{maven-surefire-plugin}} in Compatibility Framework.
> See IGNITE-8275 for details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10278) The checkpointReadLock must be acquired before calling MvccProcessor.updateState
[
https://issues.apache.org/jira/browse/IGNITE-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689392#comment-16689392
]
Andrew Mashenkov commented on IGNITE-10278:
---
Changes looks ok, can be merged.
> The checkpointReadLock must be acquired before calling
> MvccProcessor.updateState
>
>
> Key: IGNITE-10278
> URL: https://issues.apache.org/jira/browse/IGNITE-10278
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> It looks like acquiring \{{checkpointReadLock}} is missing when we are trying
> to apply mvcc tx records.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10260) MVCC: GetAndPutIfAbsent operation return no result.
[ https://issues.apache.org/jira/browse/IGNITE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10260: -- Summary: MVCC: GetAndPutIfAbsent operation return no result. (was: MVCC: GetAndPutIfAbsent operation result no result.) > MVCC: GetAndPutIfAbsent operation return no result. > --- > > Key: IGNITE-10260 > URL: https://issues.apache.org/jira/browse/IGNITE-10260 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > Next test (but may be not the only) are failed with Mvcc cache mode: > CachePutIfAbsentTest.testTxConflictGetAndPutIfAbsent() > CacheEnumOperationsSingleNodeTest.testMvccTx() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10285) U.doInParallel may lead to deadlock
[ https://issues.apache.org/jira/browse/IGNITE-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689391#comment-16689391 ] Pavel Voronkin commented on IGNITE-10285: - Looks good for me. > U.doInParallel may lead to deadlock > --- > > Key: IGNITE-10285 > URL: https://issues.apache.org/jira/browse/IGNITE-10285 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > Attachments: dump.rtf > > > There are exist case when we can get a deadlock on the thread pool. > If we try doInParallel in the thread of sys-pool in the number of > hreads==sys-pool.size we lead to deadlock because threads in sys-pool will > try doInParallel through the same sys-pool, and they will wait on future > infinitely because no one thread cannot complete operation doInParallel which > require threads from sys-pool. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10286) [ML] Umbrella: Model serving
[ https://issues.apache.org/jira/browse/IGNITE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10286: Fix Version/s: 2.8 > [ML] Umbrella: Model serving > > > Key: IGNITE-10286 > URL: https://issues.apache.org/jira/browse/IGNITE-10286 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > Fix For: 2.8 > > > We want to have convenient API for model serving. It means that we need a > mechanism for storing models and infer them inside Apache Ignite. > For now, I see 2 important features - distributed storage for any models and > inference. > From my point of view, we could use some built-in(predefined) cache as model > storage. And use service grid for model inference. We could implement some > "ModelService" for access to our storage, receive the list of all suitable > model(including model metrics and some other information about a model), > choose one(or several) and infer it from this service. > Model from TF should also use the same mechanisms for storing and inference. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation
[
https://issues.apache.org/jira/browse/IGNITE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-9312:
--
Comment: was deleted
(was: {panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2])
> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
> Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}}
> annotation regarding this inscpetion profile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10197) unexpected IllegalArgumentException in IgniteDbPutGetAbstractTest#testRandomPutGetRemove
[
https://issues.apache.org/jira/browse/IGNITE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689381#comment-16689381
]
ASF GitHub Bot commented on IGNITE-10197:
-
GitHub user ibessonov opened a pull request:
https://github.com/apache/ignite/pull/5410
IGNITE-10197 unexpected IllegalArgumentException in
IgniteDbPutGetAbstractTest#testRandomPutGetRemove
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10197
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5410.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5410
commit 5b2aedaf37f0fca7fd3f322bcabb774a7c3e61f4
Author: ibessonov
Date: 2018-11-16T12:52:25Z
IGNITE-10197 "testRandomPutGetRemove" test method was uncommented.
> unexpected IllegalArgumentException in
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove
>
>
> Key: IGNITE-10197
> URL: https://issues.apache.org/jira/browse/IGNITE-10197
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteDbPutGetAbstractTest#testRandomPutGetRemove (in current codebase muted
> by renaming to {{_testRandomPutGetRemove}}) fails with IAE:
> {noformat}java.lang.IllegalArgumentException: Ouch! Argument is invalid:
> Cache name must not be null or empty.
> at
> org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1600)
> at org.apache.ignite.internal.IgniteKernal.cache(IgniteKernal.java:2901)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.cache(IgniteDbPutGetAbstractTest.java:74)
> at
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.testRandomPutGetRemove(IgniteDbPutGetAbstractTest.java:814)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745){noformat}
> Note a while ago this test was muted by adding underscore prefix to its name
> per [commit
> 2e343b6|https://github.com/apache/ignite/commit/4282d802f16188cdea05d6b2d2c0f3c222e343b6]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation
[
https://issues.apache.org/jira/browse/IGNITE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689382#comment-16689382
]
PetrovMikhail commented on IGNITE-9312:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2331413buildTypeId=IgniteTests24Java8_Queries2]
> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
> Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}}
> annotation regarding this inscpetion profile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation
[
https://issues.apache.org/jira/browse/IGNITE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689372#comment-16689372
]
PetrovMikhail commented on IGNITE-9312:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209639]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteClientReconnectCacheQueriesFailoverTest.testReconnectCacheQueries
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteErrorOnRebalanceTest.testErrorOnRebalance
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209591]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccContinuousWithTransformerReplicatedSelfTest.testContinuousWithTransformerAndRegularListenerKeepBinaryAsync
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209547]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync -
0,0% fails in last 100 master runs.
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2331419]]
* IgniteSpiTestSuite:
IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2209538]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChangeFail
{color:#d04437}Platform .NET{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2209633]]
* exe: ClientConnectionTest.TestServerConnectionAborted - 3,1% fails in last
100 master runs.
* exe: ServicesTest.TestWithKeepBinaryClient - 0,0% fails in last 100 master
runs.
{color:#d04437}Start Nodes{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=2209571]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStopNodesFiltered - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartThreeNodesAndDoEmptyCall -
3,2% fails in last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartOneNode - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodes - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds - 3,2% fails in
last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testCustomScript - 3,2% fails in last
100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testStartFiveWithTwoSpecs - 3,2% fails
in last 100 master runs.
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered - 3,2% fails
in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209645buildTypeId=IgniteTests24Java8_RunAll]
> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
> Labels: inspections
> Fix For: 2.8
>
>
> New `Code Inspections` profile can be found
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}}
> annotation regarding this inscpetion profile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10289) [ML] Import models from XGBoost
[ https://issues.apache.org/jira/browse/IGNITE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10289: Fix Version/s: 2.8 > [ML] Import models from XGBoost > --- > > Key: IGNITE-10289 > URL: https://issues.apache.org/jira/browse/IGNITE-10289 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > We want to have the ability of import model from 3rd part ml libraries into > Apache Ignite. We could start this process from XGBoost library for trees and > GDB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10287) [ML] Model storage
[ https://issues.apache.org/jira/browse/IGNITE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10287: Fix Version/s: 2.8 > [ML] Model storage > -- > > Key: IGNITE-10287 > URL: https://issues.apache.org/jira/browse/IGNITE-10287 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Priority: Major > Fix For: 2.8 > > > We want to have some storage for any kind of models in Apache Ignite. It > should allow storing > a model from any node after training and evaluation(MB with some meta info > and model metrics) and provide API to get this model to any node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10288) [ML] Model inference
[ https://issues.apache.org/jira/browse/IGNITE-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10288: Fix Version/s: 2.8 > [ML] Model inference > > > Key: IGNITE-10288 > URL: https://issues.apache.org/jira/browse/IGNITE-10288 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Priority: Major > Fix For: 2.8 > > > We need a convenient API for model inference. The current idea is to utilize > Service Grid for this purpose. We should have two options, first is deliver a > model to any node(server or client) and infer this model on that node. The > second approach is to pin a model to a specific server and infer model on > that server, it could be useful in case if we need some specific hardware > which we don't have at any server like a GPU or TPU. > So the first approach is suitable for lightweight models and the second > approach is suitable for some complex models like Neural Networks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9999) Add verbose logging for node recovery
[ https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-: Component/s: cache > Add verbose logging for node recovery > - > > Key: IGNITE- > URL: https://issues.apache.org/jira/browse/IGNITE- > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 2.8 >Reporter: Alexey Goncharuk >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.8 > > > Sometimes we see some difficulties in understanding which state a node is > after a binary recovery and what state it has after applying all logical > records from WAL. > We need to add more information on the state of partitions (update counter, > size, maybe more additional info) after the binary recovery (can be validated > against checkpoint records) and after logical recovery (can help to validate > the correctness of rebalance). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9461) Implement random subspace method and provide an option to combine it with bagging
[
https://issues.apache.org/jira/browse/IGNITE-9461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Babak updated IGNITE-9461:
---
Fix Version/s: 2.8
> Implement random subspace method and provide an option to combine it with
> bagging
> -
>
> Key: IGNITE-9461
> URL: https://issues.apache.org/jira/browse/IGNITE-9461
> Project: Ignite
> Issue Type: Task
> Components: ml
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
>
> Implement random subspace method (aka attribute bagging or feature bagging)
> to give ML API users more options to address overfitting. Also provide an
> option to combine this method with bagging.
> References:
> * [Wikipedia article|https://en.wikipedia.org/wiki/Random_subspace_method]
> {quote}Informally, this causes individual learners to not over-focus on
> features that appear highly predictive/descriptive in the training set, but
> fail to be as predictive for points outside that set. For this reason, random
> subspaces are an attractive choice for problems where the number of features
> is much larger than the number of training points, such as learning from fMRI
> data or gene expression data...{quote}
> * [Combining Bagging and Random Subspaces to Create Better
> Ensembles|https://pdfs.semanticscholar.org/d38f/979ad85d59fc93058279010efc73a24a712c.pdf]
> * [Bagging and the Random Subspace Method for Redundant Feature
> Spaces|https://link.springer.com/chapter/10.1007/3-540-48219-9_1]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10272) [ML] Inject learning environment into scope of dataset compute task
[ https://issues.apache.org/jira/browse/IGNITE-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10272: Fix Version/s: 2.8 > [ML] Inject learning environment into scope of dataset compute task > --- > > Key: IGNITE-10272 > URL: https://issues.apache.org/jira/browse/IGNITE-10272 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > We want to have learing environment for each partition during training > process. We need this for several reasons. > The first one is logging training process for each partition. The second > reason is having the possibility of fixing random number generator seed for > tests and debugging(fixing subspace distribution, stable tests, etc...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
