[jira] [Created] (IGNITE-12281) Data search from Ignite Cache value object
ROHIT SANGWAN created IGNITE-12281: -- Summary: Data search from Ignite Cache value object Key: IGNITE-12281 URL: https://issues.apache.org/jira/browse/IGNITE-12281 Project: Ignite Issue Type: Wish Reporter: ROHIT SANGWAN Hi Team, I am solution for data look up from Ignite cache value. I found multiple operation where I can use key to get the value. But I have a use case where I want to apply search on few attributes of value on a certain cache. I tried scan query but its very costly operation. Please help me to find a effective solution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10683) Prepare process of packaging and delivering thin clients
[
https://issues.apache.org/jira/browse/IGNITE-10683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948990#comment-16948990
]
Igor Sapego commented on IGNITE-10683:
--
I believe, we should release them alongside this time, and then we can release
them separately as needed.
[~mmuzaf] I think we can. [~vveider] what do you think?
> Prepare process of packaging and delivering thin clients
>
>
> Key: IGNITE-10683
> URL: https://issues.apache.org/jira/browse/IGNITE-10683
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.8
>
>
> # **NodeJs client**
> #* +Instruction+:
> https://github.com/nobitlost/ignite/blob/ignite--docs/modules/platforms/nodejs/README.md#publish-ignite-nodejs-client-on-npmjscom-instruction
> #* +Uploaded+: https://www.npmjs.com/package/apache-ignite-client
> # **PHP client**
> #* +Instruction+:
> https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md#release-the-client-in-the-php-package-repository-instruction
> {panel}
> Cannot be uploaded on Packagist as the client should be in a dedicated
> repository for that -
> https://issues.apache.org/jira/browse/IGNITE-7783?focusedCommentId=16595476=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16595476
> Installation from the sources works.
> {panel}
> # **Python client**
> I have already registered the package `pyignite` on PyPI[1]. The person who
> is going to take the responsibility of maintaining it should create an
> account on PyPI and mail me in private, so that I can grant them the
> necessary rights. They also must install twine[3].
> The process of packaging is well described in the packaging tutorial[2]. In
> the nutshell, the maintainer must do the following:
> ## Clone/pull the sources from the git repository,
> ## Enter the directory in which the `setup.py` is resides (“the setup
> directory”), in our case it is `modules/platforms/python`.
> ## Create the packages with the command `python3 setup.py sdist bdist_wheel`.
> The packages will be created in `modules/platforms/python/dist` folder.
> ## Upload packages with twine: `twine upload dist/*`.
> It is very useful to have a dedicated Python virtual environment prepared to
> perform steps 3-4. Just do an editable install of `pyignite` into that
> environment from the setup directory: `pip3 install -e .` You can also
> install twine (`pip install twine`) in it.
> Consider also making a `.pypirc` file to save time on logging in to PyPI.
> Newest version of `twine` is said to support keyrings on Linux and Mac, but I
> have not tried this yet.
> [1] https://pypi.org/project/pyignite/
> [2] https://packaging.python.org/tutorials/packaging-projects/
> [3] https://twine.readthedocs.io/en/latest/
> Some other notes on PyPI and versioning.
> - The package version is located in the `setup.py`, it is a `version`
> argument of the `setuptools.setup()` function. Editing the `setup.py` is the
> only way to set the package version.
> - You absolutely can not replace a package in PyPI (hijacking prevention). If
> you have published the package by mistake, all you can do is delete the
> unwanted package, increment the version counter in `setup.py`, and try again.
> - If you upload the package through the web interface of PyPI (without
> twine), the package description will be garbled. Web interface does not
> support markdown.
> Anyway, I would like to join in the congratulations on successful release.
> Kudos to the team.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12193) [Phase-1] Rebalancing cache group keys metric counters
[
https://issues.apache.org/jira/browse/IGNITE-12193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948956#comment-16948956
]
Ignite TC Bot commented on IGNITE-12193:
{panel:title=Branch: [pull/6960/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4682945buildTypeId=IgniteTests24Java8_RunAll]
> [Phase-1] Rebalancing cache group keys metric counters
> --
>
> Key: IGNITE-12193
> URL: https://issues.apache.org/jira/browse/IGNITE-12193
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Nikolai Kulagin
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Implement metrics counters related to the cache group:
> * rebalancingPartitionsLeft long metric
> * rebalancingReceivedKeys long metric
> * rebalancingReceivedBytes long metric
> * rebalancingStartTime long metric
> * rebalancingFinishTime long metric
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12280) Removal of this limitation "It's not recommended to have class hierarchies with raw reading/writing"
Sam created IGNITE-12280: Summary: Removal of this limitation "It's not recommended to have class hierarchies with raw reading/writing" Key: IGNITE-12280 URL: https://issues.apache.org/jira/browse/IGNITE-12280 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.7 Reporter: Sam when tried to use raw mode with a class chain where both extending class and superclass calls rawReader(), facing "org.apache.ignite.binary.BinaryObjectException: Method rawReader can be called only once." . This seems to be a limitation that needs extra programmatic workaround to support hierarchy or chain of classes in serializer/deserializer. Extra code has the hassle of maintenance and quite different from other tools. more details on user group [http://apache-ignite-users.70518.x6.nabble.com/Exception-Method-rawReader-can-be-called-only-once-td29556.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948947#comment-16948947
]
Ignite TC Bot commented on IGNITE-12220:
{panel:title=Branch: [pull/6904/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4683308buildTypeId=IgniteTests24Java8_RunAll]
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948825#comment-16948825 ] Igor Sapego commented on IGNITE-8411: - I've move it to 2.9 > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-8411: Fix Version/s: (was: 2.8) 2.9 > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12279) Add support for using H2O MOJO models for inference
[ https://issues.apache.org/jira/browse/IGNITE-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal updated IGNITE-12279: Description: We would like to see support for using H2O MOJO models for inference (similar to xgboost/mleap) > Add support for using H2O MOJO models for inference > --- > > Key: IGNITE-12279 > URL: https://issues.apache.org/jira/browse/IGNITE-12279 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Michal >Priority: Major > > We would like to see support for using H2O MOJO models for inference (similar > to xgboost/mleap) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12279) Add support for using H2O MOJO models for inference
[ https://issues.apache.org/jira/browse/IGNITE-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948819#comment-16948819 ] Michal commented on IGNITE-12279: - PR will follow > Add support for using H2O MOJO models for inference > --- > > Key: IGNITE-12279 > URL: https://issues.apache.org/jira/browse/IGNITE-12279 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Michal >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12279) Add support for using H2O MOJO models for inference
Michal created IGNITE-12279: --- Summary: Add support for using H2O MOJO models for inference Key: IGNITE-12279 URL: https://issues.apache.org/jira/browse/IGNITE-12279 Project: Ignite Issue Type: New Feature Components: ml Reporter: Michal -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12278) Add metric showing how many nodes may safely leave the cluster wihout partition loss
[ https://issues.apache.org/jira/browse/IGNITE-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-12278: Description: We already have CacheGroupMetricsMXBean#getMinimumNumberOfPartitionCopies metrics that shows partitions redundancy number for a specific cache group. It would be handy if user has single aggregated metric for all cache groups showing how many nodes may leave the cluster without partition loss in any cache. was: We already have getMinimumNumberOfPartitionCopies metrics that shows partitions redundancy number for a specific cache group. It would be handy if user has single aggregated metric for all cache groups showing how many nodes may leave the cluster without partition loss in any cache. > Add metric showing how many nodes may safely leave the cluster wihout > partition loss > > > Key: IGNITE-12278 > URL: https://issues.apache.org/jira/browse/IGNITE-12278 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Priority: Major > Labels: newbie > Fix For: 2.8 > > > We already have CacheGroupMetricsMXBean#getMinimumNumberOfPartitionCopies > metrics that shows partitions redundancy number for a specific cache group. > It would be handy if user has single aggregated metric for all cache groups > showing how many nodes may leave the cluster without partition loss in any > cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12278) Add metric showing how many nodes may safely leave the cluster wihout partition loss
Ivan Rakov created IGNITE-12278: --- Summary: Add metric showing how many nodes may safely leave the cluster wihout partition loss Key: IGNITE-12278 URL: https://issues.apache.org/jira/browse/IGNITE-12278 Project: Ignite Issue Type: Improvement Reporter: Ivan Rakov Fix For: 2.8 We already have getMinimumNumberOfPartitionCopies metrics that shows partitions redundancy number for a specific cache group. It would be handy if user has single aggregated metric for all cache groups showing how many nodes may leave the cluster without partition loss in any cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12172) [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
[
https://issues.apache.org/jira/browse/IGNITE-12172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov updated IGNITE-12172:
--
Component/s: build
> [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
> --
>
> Key: IGNITE-12172
> URL: https://issues.apache.org/jira/browse/IGNITE-12172
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Andrey N. Gura
>Assignee: Peter Ivanov
>Priority: Major
> Labels: IEP-35, await
>
> {{OpenCensusMetricExporterSpiTest}} isn't added to any test suite. As result
> tests do not run on TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12172) [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
[
https://issues.apache.org/jira/browse/IGNITE-12172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948712#comment-16948712
]
Peter Ivanov edited comment on IGNITE-12172 at 10/10/19 3:48 PM:
-
Prepared: [Open
Census|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_OpenCensus],
added to Run All.
was (Author: vveider):
Prepared: [Open
Census|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_OpenCensus]
> [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
> --
>
> Key: IGNITE-12172
> URL: https://issues.apache.org/jira/browse/IGNITE-12172
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Peter Ivanov
>Priority: Major
> Labels: IEP-35, await
>
> {{OpenCensusMetricExporterSpiTest}} isn't added to any test suite. As result
> tests do not run on TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12172) [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
[
https://issues.apache.org/jira/browse/IGNITE-12172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov resolved IGNITE-12172.
---
Fix Version/s: (was: 2.8)
Resolution: Done
Prepared: [Open
Census|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_OpenCensus]
> [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
> --
>
> Key: IGNITE-12172
> URL: https://issues.apache.org/jira/browse/IGNITE-12172
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Peter Ivanov
>Priority: Major
> Labels: IEP-35, await
>
> {{OpenCensusMetricExporterSpiTest}} isn't added to any test suite. As result
> tests do not run on TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9732) [Spark] Add joins to Spark Dataframe examples
[
https://issues.apache.org/jira/browse/IGNITE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-9732:
Summary: [Spark] Add joins to Spark Dataframe examples (was: Add joins to
Spark Dataframe examples)
> [Spark] Add joins to Spark Dataframe examples
> -
>
> Key: IGNITE-9732
> URL: https://issues.apache.org/jira/browse/IGNITE-9732
> Project: Ignite
> Issue Type: Improvement
> Components: examples, spark
>Affects Versions: 2.8
>Reporter: Valentin Kulichenko
>Assignee: Alexey Zinoviev
>Priority: Critical
> Labels: await
> Fix For: 2.8
>
>
> {{IgniteDataFrameExample}} creates two tables - {{city}} and {{person}}, but
> only {{person}} is actually used. Need to add join examples.
> Would also be great to demonstrate the fact that optimization is working and
> joins are executed in Ignite, not Spark (using {{explain()}}, maybe?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12172) [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
[
https://issues.apache.org/jira/browse/IGNITE-12172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov reassigned IGNITE-12172:
-
Assignee: Peter Ivanov
> [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
> --
>
> Key: IGNITE-12172
> URL: https://issues.apache.org/jira/browse/IGNITE-12172
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Peter Ivanov
>Priority: Major
> Labels: IEP-35, await
> Fix For: 2.8
>
>
> {{OpenCensusMetricExporterSpiTest}} isn't added to any test suite. As result
> tests do not run on TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12172) [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
[
https://issues.apache.org/jira/browse/IGNITE-12172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948702#comment-16948702
]
Nikolay Izhikov commented on IGNITE-12172:
--
Hello [~vveider]. Can you, please, help us with this ticket?
> [IEP-35] OpenCensusMetricExporterSpiTest isn't added to any test suite
> --
>
> Key: IGNITE-12172
> URL: https://issues.apache.org/jira/browse/IGNITE-12172
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: IEP-35, await
> Fix For: 2.8
>
>
> {{OpenCensusMetricExporterSpiTest}} isn't added to any test suite. As result
> tests do not run on TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12232) NPE while node join processing
[ https://issues.apache.org/jira/browse/IGNITE-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948691#comment-16948691 ] Andrey Kuznetsov commented on IGNITE-12232: --- I've examined the fix. And it looks ok to me. > NPE while node join processing > -- > > Key: IGNITE-12232 > URL: https://issues.apache.org/jira/browse/IGNITE-12232 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: PetrovMikhail >Assignee: Ryabov Dmitrii >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > ServerImpl.RingMessageWorker#processNodeAddedMessage method throws npe > exception in case DiscoverySpiNodeAuthenticator#authenticateNode returns null. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948677#comment-16948677 ] Andrey Mashenkov commented on IGNITE-12189: --- Thanks. I've just found you apply 'limit' on reduce side inside CacheQueryFutureAdapter. Assume, you have few nodes, small pageSize (10 entries per page) and large enough 'limit' = 1000. So, you'll get about 100 pages from every node and about 1000 in total, but most likely you want only first 100 pages. For now query initiator node sends 1 GridCacheQueryRequest and can get multiple GridCacheQueryResponse-s per remote. TextQuery processing finishes when all remotes send GridCacheQueryResponse with 'finished' flag. Seems, TextQuery processing should be reworked like it was done for SQL queries. Ignite has GridQueryNextPageRequest \ Response classes for SQL result processing. Similar processing should be implemented for TextQueries. This looks like a big change which allow us to add correct sorting and apply limit correctly on reduce . Let's create a separate ticket for this and link it to current one, then I'll merge PR to master. > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11981) [IEP-35] Create MU shortcut instead of static import of MetricUtils
[
https://issues.apache.org/jira/browse/IGNITE-11981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-11981.
--
Resolution: Won't Fix
> [IEP-35] Create MU shortcut instead of static import of MetricUtils
> ---
>
> Key: IGNITE-11981
> URL: https://issues.apache.org/jira/browse/IGNITE-11981
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Minor
> Labels: IEP-35
>
> More Ignite-way of coding is the usage of short cut classes.
> We should use MU instead of static import of {{MetricUtils}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type
[ https://issues.apache.org/jira/browse/IGNITE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev reassigned IGNITE-9229: --- Assignee: Alexey Zinoviev > Integration with Spark Data Frame. Add support for a ARRAY data type > > > Key: IGNITE-9229 > URL: https://issues.apache.org/jira/browse/IGNITE-9229 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.9 >Reporter: Nikolay Izhikov >Assignee: Alexey Zinoviev >Priority: Critical > > Currently, integration with Spark Data Frames doesn't support ARRAY data type. > We need to add support for it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12159) Ignite spark doesn't support Alter Column syntax
[
https://issues.apache.org/jira/browse/IGNITE-12159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev resolved IGNITE-12159.
--
Resolution: Fixed
> Ignite spark doesn't support Alter Column syntax
>
>
> Key: IGNITE-12159
> URL: https://issues.apache.org/jira/browse/IGNITE-12159
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.8
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Zinoviev
>Priority: Critical
> Labels: await
> Fix For: 2.8
>
>
> Steps:
> 1)Start the server
> 2)Run next SQL commands
> CREATE TABLE person (id LONG, name VARCHAR(64), age LONG, city_id DOUBLE,
> zip_code LONG, PRIMARY KEY (name)) WITH "backups=1"
> ALTER TABLE person ADD COLUMN (first_name VARCHAR(64), last_name VARCHAR(64))
> 3)After that run next spark code:
> String configPath = "client.xml";
>
> SparkConf sparkConf = new SparkConf()
> .setMaster("local")
> .setAppName("Example");
> IgniteSparkSession.builder()
> .appName("Spark Ignite catalog example")
> .master("local")
> .config("ignite.disableSparkSQLOptimization", true)
> .igniteConfig(configPath)
> .getOrCreate();
>
> Dataset df2 = igniteSession.sql("select * from person");
> df2.show();
> The result will contain only 5 columns from CREATE TABLE call.
> [http://apache-ignite-users.70518.x6.nabble.com/Altered-sql-table-adding-new-columns-does-not-reflect-in-Spark-shell-td29265.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type
[ https://issues.apache.org/jira/browse/IGNITE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948664#comment-16948664 ] Alexey Zinoviev commented on IGNITE-9229: - Hmm, missed this in Java.sql.types, will know about that. Agree with your position, will leave this ticket for future > Integration with Spark Data Frame. Add support for a ARRAY data type > > > Key: IGNITE-9229 > URL: https://issues.apache.org/jira/browse/IGNITE-9229 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.9 >Reporter: Nikolay Izhikov >Assignee: Alexey Zinoviev >Priority: Critical > > Currently, integration with Spark Data Frames doesn't support ARRAY data type. > We need to add support for it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type
[ https://issues.apache.org/jira/browse/IGNITE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev reassigned IGNITE-9229: --- Assignee: (was: Alexey Zinoviev) > Integration with Spark Data Frame. Add support for a ARRAY data type > > > Key: IGNITE-9229 > URL: https://issues.apache.org/jira/browse/IGNITE-9229 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.9 >Reporter: Nikolay Izhikov >Priority: Critical > > Currently, integration with Spark Data Frames doesn't support ARRAY data type. > We need to add support for it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type
[
https://issues.apache.org/jira/browse/IGNITE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948631#comment-16948631
]
Nikolay Izhikov commented on IGNITE-9229:
-
Hello.
I think we can throw an exception for now and just leave this ticket.
I'm not sure that ARRAY type comes from NoSQL.
Take a look at {{java.sql.Types#ARRAY}}. It was here since java 1.2.
So, I think, Ignite will support this datatype one day.
After that day we can implement support for spark integration.
> Integration with Spark Data Frame. Add support for a ARRAY data type
>
>
> Key: IGNITE-9229
> URL: https://issues.apache.org/jira/browse/IGNITE-9229
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.9
>Reporter: Nikolay Izhikov
>Assignee: Alexey Zinoviev
>Priority: Critical
>
> Currently, integration with Spark Data Frames doesn't support ARRAY data type.
> We need to add support for it
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948629#comment-16948629 ] Yuriy Shuliha commented on IGNITE-12189: - [~amashenkov] - I have made corrections according to your notes. Here's the tests run result (above). Can the PR be merged now ? > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11852) Assertion errors when changing PME coordinator to locally joining node
[
https://issues.apache.org/jira/browse/IGNITE-11852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11852:
-
Priority: Critical (was: Major)
> Assertion errors when changing PME coordinator to locally joining node
> --
>
> Key: IGNITE-11852
> URL: https://issues.apache.org/jira/browse/IGNITE-11852
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5, 2.7
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When PME coordinator changed to locally joining node several assertion errors
> may occur:
> 1. When some other joining nodes finished PME:
> {noformat}
> [13:49:58] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1...@27296181java.lang.AssertionError:
> AffinityTopologyVersion [topVer=2, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$11.applyx(CacheAffinitySharedManager.java:1546)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$11.applyx(CacheAffinitySharedManager.java:1535)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.lambda$forAllRegisteredCacheGroups$e0a6939d$1(CacheAffinitySharedManager.java:1281)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10929)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10831)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10811)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1280)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onLocalJoin(CacheAffinitySharedManager.java:1535)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4189)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onBecomeCoordinator(GridDhtPartitionsExchangeFuture.java:4731)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$3400(GridDhtPartitionsExchangeFuture.java:145)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:4622)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:4611)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:466)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:281)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:143)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:44)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:455)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.InitNewCoordinatorFuture.onMessage(InitNewCoordinatorFuture.java:253)
> at
>
[jira] [Updated] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10417: - Priority: Critical (was: Major) > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Fix For: 2.8 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9732) Add joins to Spark Dataframe examples
[
https://issues.apache.org/jira/browse/IGNITE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9732:
Priority: Critical (was: Major)
> Add joins to Spark Dataframe examples
> -
>
> Key: IGNITE-9732
> URL: https://issues.apache.org/jira/browse/IGNITE-9732
> Project: Ignite
> Issue Type: Improvement
> Components: examples, spark
>Affects Versions: 2.8
>Reporter: Valentin Kulichenko
>Assignee: Alexey Zinoviev
>Priority: Critical
> Labels: await
> Fix For: 2.8
>
>
> {{IgniteDataFrameExample}} creates two tables - {{city}} and {{person}}, but
> only {{person}} is actually used. Need to add join examples.
> Would also be great to demonstrate the fact that optimization is working and
> joins are executed in Ignite, not Spark (using {{explain()}}, maybe?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11147) Dynamic cache start during rebalance leads to start rebalance for all cache groups in case of IGNITE_DISABLE_WAL_DURING_REBALANCING = true
[ https://issues.apache.org/jira/browse/IGNITE-11147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11147: - Priority: Critical (was: Blocker) > Dynamic cache start during rebalance leads to start rebalance for all cache > groups in case of IGNITE_DISABLE_WAL_DURING_REBALANCING = true > -- > > Key: IGNITE-11147 > URL: https://issues.apache.org/jira/browse/IGNITE-11147 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Sergey Antonov >Assignee: Vladislav Pyatkov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Scenario: > 1) Start cluster with PDS and option (IGNITE_DISABLE_WAL_DURING_REBALANCING = > true). Activate cluster and start few dinymic caches. > 2) Stop one node and clean its PDS. > 3) Start the node again. It's come back to the cluster. Rebalance started. > 4) During rebalance start some caches (part of them should be already started > on nodes). > Expected: > Rebalance will be started only for new caches. For other nodes rebalance > willn't canceled. > Actual: > Rebalance wiil be canceled and starts again for all cache groups (including > rebalanced yet) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type
[ https://issues.apache.org/jira/browse/IGNITE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948604#comment-16948604 ] Alexey Zinoviev commented on IGNITE-9229: - Dear [~nizhikov] there is no SQL Type ARRAY here [https://apacheignite-sql.readme.io/docs/data-types] Historically, ARRAY type in Spark comes from Hive and Hadoop and NoSQL world to be competitor with Mongo and so on. If we will not ask SQL maintainers to add this function, how do you think it can be implemented in Spark-Ignite integration? Maybe the best case - Note about this limitation and throw exception? Or keep it like a STRING field in IGNITE with additional metadata? > Integration with Spark Data Frame. Add support for a ARRAY data type > > > Key: IGNITE-9229 > URL: https://issues.apache.org/jira/browse/IGNITE-9229 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.9 >Reporter: Nikolay Izhikov >Assignee: Alexey Zinoviev >Priority: Critical > > Currently, integration with Spark Data Frames doesn't support ARRAY data type. > We need to add support for it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948594#comment-16948594
]
Pavel Tupitsyn commented on IGNITE-12033:
-
[~mmuzaf] I would prefer to keep the original ticket so we can make sure Java
fix also resolves .NET issue. A test is certainly needed.
But ok, let's keep it as is.
Unassigned from myself.
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.8
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-12033:
---
Assignee: (was: Pavel Tupitsyn)
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.8
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12033:
Labels: (was: .NET)
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.8
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12033:
Labels: .NET (was: )
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.8
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948589#comment-16948589
]
Maxim Muzafarov commented on IGNITE-12033:
--
[~ptupitsyn]
Will you be able to fix this issue on the java side? Can you unassigned the
issue from yourself if not?
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.8
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948588#comment-16948588
]
Maxim Muzafarov commented on IGNITE-12033:
--
Folks,
I've updated a bit the issue description. It seems we don't need to create a
separate ticket to solve this issue on java side.
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.8
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12033:
-
Description:
Discussed on dev-list:
http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
*Must use the public pool for callbacks as the most obvious step.*
http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
There's a reproducer project. Long story short, .Net can invoke cache
operations with future callbacks, which will be invoked from striped pool. If
such callbacks are to use cache operations, those will be possibly sheduled to
the same stripe and cause a deadlock.
The code is very simple:
{code}
Console.WriteLine("PutAsync");
await cache.PutAsync(1, "Test");
Console.WriteLine("Replace");
cache.Replace(1, "Testing"); // Hangs here
Console.WriteLine("Wait");
await Task.Delay(Timeout.Infinite);
{code}
async/await should absolutely not allow any client code to be run from stripes.
was:
http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
There's a reproducer project. Long story short, .Net can invoke cache
operations with future callbacks, which will be invoked from striped pool. If
such callbacks are to use cache operations, those will be possibly sheduled to
the same stripe and cause a deadlock.
The code is very simple:
{code}
Console.WriteLine("PutAsync");
await cache.PutAsync(1, "Test");
Console.WriteLine("Replace");
cache.Replace(1, "Testing"); // Hangs here
Console.WriteLine("Wait");
await Task.Delay(Timeout.Infinite);
{code}
async/await should absolutely not allow any client code to be run from stripes.
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.8
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12033:
-
Summary: Callbacks from striped pool due to async/await may hang cluster
(was: .NET: Callbacks from striped pool due to async/await may hang cluster)
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.8
>
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12033) .NET: Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12033:
-
Labels: (was: .net)
> .NET: Callbacks from striped pool due to async/await may hang cluster
> -
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.8
>
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-12233) Merge benchmarks sql index benchmarks from ignite-2.7 to master
[ https://issues.apache.org/jira/browse/IGNITE-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Suntsov closed IGNITE-12233. - > Merge benchmarks sql index benchmarks from ignite-2.7 to master > --- > > Key: IGNITE-12233 > URL: https://issues.apache.org/jira/browse/IGNITE-12233 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Ilya Suntsov >Assignee: Ilya Suntsov >Priority: Major > Fix For: 2.8 > > > The following benchmarks are missed in master but exist in ignite-2.7: > * IgniteSqlUpdateFilteredBenchmark > * IgniteSqlInsertIndexedValue1Benchmark > * IgniteSqlInsertIndexedValue2Benchmark > * IgniteSqlInsertIndexedValue8Benchmark -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12233) Merge benchmarks sql index benchmarks from ignite-2.7 to master
[ https://issues.apache.org/jira/browse/IGNITE-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12233: - Ignite Flags: (was: Docs Required,Release Notes Required) > Merge benchmarks sql index benchmarks from ignite-2.7 to master > --- > > Key: IGNITE-12233 > URL: https://issues.apache.org/jira/browse/IGNITE-12233 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Ilya Suntsov >Assignee: Ilya Suntsov >Priority: Major > Fix For: 2.8 > > > The following benchmarks are missed in master but exist in ignite-2.7: > * IgniteSqlUpdateFilteredBenchmark > * IgniteSqlInsertIndexedValue1Benchmark > * IgniteSqlInsertIndexedValue2Benchmark > * IgniteSqlInsertIndexedValue8Benchmark -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-4603) Python: basic Data Grid API
[ https://issues.apache.org/jira/browse/IGNITE-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-4603: Fix Version/s: 2.8 > Python: basic Data Grid API > --- > > Key: IGNITE-4603 > URL: https://issues.apache.org/jira/browse/IGNITE-4603 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis A. Magda >Priority: Major > Fix For: 2.8 > > > Implement basic Data Grid API similar to the scope covered by C++: > https://apacheignite-cpp.readme.io/docs/data-grid -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12018) Web Agent docker image: 'functions.sh' not found
[
https://issues.apache.org/jira/browse/IGNITE-12018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12018:
-
Fix Version/s: 2.8
> Web Agent docker image: 'functions.sh' not found
>
>
> Key: IGNITE-12018
> URL: https://issues.apache.org/jira/browse/IGNITE-12018
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.7, 2.7.5
>Reporter: Igor Belyakov
>Assignee: Saikat Maitra
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Steps to reproduce:
> 1. Build docker image by using "docker/web-agent/Dockerfile" according to
> README file.
> 2. Start docker container by using generated image.
> 3. Next error happens on container start:
>
> {code:java}
> ./ignite-web-agent.sh: line 39:
> /opt/ignite/ignite-web-agent/include/functions.sh: No such file or directory
> ./ignite-web-agent.sh: line 44: checkJava: command not found
> ./ignite-web-agent.sh: line 64: javaMajorVersion: command not found
> ./ignite-web-agent.sh: line 66: [: -eq: unary operator expected
> ./ignite-web-agent.sh: line 71: [: -gt: unary operator expected
> ./ignite-web-agent.sh: line 84: [: -eq: unary operator expected
> ./ignite-web-agent.sh: line 95: : command not found{code}
>
> Image contains next files in "/opt/ignite/ignite-web-agent" directory without
> any sub directories:
>
> {code:java}
> -rw-r--r-- 1 root root 89 Dec 4 2018 README.txt
> -rw-r--r-- 1 root root 8080 Dec 4 2018 db-init.sql
> -rw-rw-r-- 1 root root 203 Jul 25 12:30 default.properties
> -rwxr-xr-x 1 root root 2721 Dec 4 2018 functions.sh
> -rw-r--r-- 1 root root 29118502 Dec 6 2018 ignite-web-agent-2.7.0.jar
> -rw-r--r-- 1 root root 4590 Dec 4 2018 ignite-web-agent.bat
> -rw-rw-r-- 1 root root 561 Jul 25 16:31 ignite-web-agent.log
> -rwxr-xr-x 1 root root 3229 Jul 25 16:33 ignite-web-agent.sh
> {code}
> The issue happens during executing files copy command in Dockerfile, it
> doesn't keep directories structure. To solve this problem "COPY
> ignite-web-agent*/* ./" command should be changed to "COPY ignite-web-agent*
> ./"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-4052: Fix Version/s: 2.8 > Add ability to set up users for MESOS > - > > Key: IGNITE-4052 > URL: https://issues.apache.org/jira/browse/IGNITE-4052 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Prachi Garg >Priority: Trivial > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > In current implementation Ignite Mesos Framework connects to MESOS cluster > via current user. Need to add ability to configure this parameters via system > env properties. Also need to add properties for mesos role. > See org/apache/ignite/mesos/IgniteFramework.java:537 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11880) [TC Bot] Configurable notifications by build parameters/suite IDS & names
[
https://issues.apache.org/jira/browse/IGNITE-11880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11880:
-
Fix Version/s: 2.8
> [TC Bot] Configurable notifications by build parameters/suite IDS & names
> -
>
> Key: IGNITE-11880
> URL: https://issues.apache.org/jira/browse/IGNITE-11880
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitry Pavlov
>Assignee: Dmitry Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Support tagging build by custom rules, not only by build parameters, e.g.
> suite name
> Support configuring custom notification channels by tags present in suite.
> Special filtering parameters option for Tc configuration now can be used for
> filtering build and tagging it.
> {noformat}
> "filteringParameters": [
> {
> "name": "env.JAVA_HOME",
> "selection": [
> {"value":"%env.JDK_ORA_18%", "label":"JDK8"},
> {"value":"%env.JDK_ORA_9%", "label":"JDK9"},
> {"value":"%env.JDK_ORA_10%", "label":"JDK10"},
> {"value":"%env.JDK_OPEN_11%", "label":"JDK11"}
> ]
> }
> ]
> {noformat}
> Improve this feature by special parameter names, like _suiteName and regexps
> in value
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7011) Web console: add more tests
[ https://issues.apache.org/jira/browse/IGNITE-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7011: Fix Version/s: 2.8 > Web console: add more tests > --- > > Key: IGNITE-7011 > URL: https://issues.apache.org/jira/browse/IGNITE-7011 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Fix For: 2.8 > > > Web console does not have enough test coverage, let's fix that. > Rough plan: > 1. Choose E2E testing framework. > 2. Investigate/implement mechanism for reproducible test environment (backend > DB, running web-agent and Ignite clusters). > 3. Write some reproducible tests. > 4. Setup CI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11994) [TC Bot] Prepare new view to select base branch and other build parameters
[ https://issues.apache.org/jira/browse/IGNITE-11994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11994: - Fix Version/s: 2.8 > [TC Bot] Prepare new view to select base branch and other build parameters > -- > > Key: IGNITE-11994 > URL: https://issues.apache.org/jira/browse/IGNITE-11994 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > New view required for reports view and for VISAs creation for non-standard > master branches, > additional features may be contributed to this new view later -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11808) Scale test execution time constant along in IgniteCacheCrossCacheTxFailoverTest
[
https://issues.apache.org/jira/browse/IGNITE-11808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11808:
-
Fix Version/s: 2.8
> Scale test execution time constant along in
> IgniteCacheCrossCacheTxFailoverTest
> ---
>
> Key: IGNITE-11808
> URL: https://issues.apache.org/jira/browse/IGNITE-11808
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Execution time of {{IgniteCacheCrossCacheTxFailoverTest}} is scaled by using
> {{ScaleFactorUtil}}. Currently an explicit constant is used to define test
> execution timeout and a magic constant is used after scaling to define a
> duration of the test. It is better to use the explicit constant throughout.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null
[
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-5994:
Fix Version/s: 2.8
> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments: IgniteCacheSelfTest.java,
> master_8629b50d6f_ignite-5994.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but
> the IgniteInternalCache.invokeAsync().get() can return the null in case when
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10094) TC: Introduce overnight builds
[ https://issues.apache.org/jira/browse/IGNITE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10094: - Fix Version/s: 2.8 > TC: Introduce overnight builds > -- > > Key: IGNITE-10094 > URL: https://issues.apache.org/jira/browse/IGNITE-10094 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > Creating this ticket to collect all efforts on shortening a single TC run and > introduce overnight TC runs. > From the infrastructure side, we need to create a separate run configuration > (for example, Run All Nightly). To begin, Run All Nightly will delegate to > Run All and later we will move several long-running suites to the nightly > run. Nightly Run All should have a nightly trigger. > From the TC bot side, we need to configure it to push nightly builds when TC > is idle and additionally to track new failures in nightly runs. > From the code side, we need to define an environment property that should > distinguish a quick run from the nightly run. Later this property will be > used to scale tests duration. > [~dpavlov], [~sergey-chugunov], [~vveider], can you chime in? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[
https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948574#comment-16948574
]
Ignite TC Bot commented on IGNITE-12189:
{panel:title=Branch: [pull/6917/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4679683buildTypeId=IgniteTests24Java8_RunAll]
> Implement correct limit for TextQuery
> -
>
> Key: IGNITE-12189
> URL: https://issues.apache.org/jira/browse/IGNITE-12189
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Yuriy Shuliha
>Assignee: Yuriy Shuliha
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> PROBLEM
> For now each server-node returns all response records to the client-node and
> it may contain ~thousands, ~hundred thousands records.
> Event if we need only first 10-100. Again, all the results are added to
> queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages.
> There are no any means to deliver deterministic result.
> SOLUTION
> Implement _*limit*_ as parameter for _*TextQuery*_ and
> _*GridCacheQueryRequest*_
> It should be passed as limit parameter in Lucene's
> _*IndexSearcher.search()*_ in _*GridLuceneIndex*_.
> For distributed queries _*limit*_ will also trim response queue when merging
> results.
> Type: long
> Special value: : 0 -> No limit (Integer.MAX_VALUE);
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-1188) We need to document Visor Cmd
[ https://issues.apache.org/jira/browse/IGNITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-1188: Fix Version/s: 2.8 > We need to document Visor Cmd > - > > Key: IGNITE-1188 > URL: https://issues.apache.org/jira/browse/IGNITE-1188 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: sprint-1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > We need to give a list of Visor Commands. > Describe interactive and batch modes. > Give several examples of most useful commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10124) [TC Bot] Redesign and refactor UI
[ https://issues.apache.org/jira/browse/IGNITE-10124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10124: - Fix Version/s: 2.8 > [TC Bot] Redesign and refactor UI > - > > Key: IGNITE-10124 > URL: https://issues.apache.org/jira/browse/IGNITE-10124 > Project: Ignite > Issue Type: Task >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Minor > Fix For: 2.8 > > > We must make the TC bot more user-friendly, make UI more intuitive and simple -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10121) Web console: Create documentation how to run Web agent as Docker image
[ https://issues.apache.org/jira/browse/IGNITE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10121: - Fix Version/s: 2.8 > Web console: Create documentation how to run Web agent as Docker image > -- > > Key: IGNITE-10121 > URL: https://issues.apache.org/jira/browse/IGNITE-10121 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > Fix For: 2.8 > > > Especially specify ho configure path to external folder with jdbc driver. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11475) [ML] Vectorizer API prototype with POC
[ https://issues.apache.org/jira/browse/IGNITE-11475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11475: - Fix Version/s: 2.8 > [ML] Vectorizer API prototype with POC > --- > > Key: IGNITE-11475 > URL: https://issues.apache.org/jira/browse/IGNITE-11475 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Critical > Labels: stability > Fix For: 2.8 > > > We need to create a prototype of API for features/labels extraction and > introduce it to one or two already existing examples. This prototype should > show that new API works on binary builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8310) CPP: Remove strong dependency on Boost 1.58.0
[ https://issues.apache.org/jira/browse/IGNITE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-8310: Fix Version/s: 2.8 > CPP: Remove strong dependency on Boost 1.58.0 > - > > Key: IGNITE-8310 > URL: https://issues.apache.org/jira/browse/IGNITE-8310 > Project: Ignite > Issue Type: Improvement > Components: odbc, platforms >Affects Versions: 2.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: boost, cpp, odbc > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, tests for C++ client and ODBC depend on the Boost 1.58.0. There is > a strong dependency on the exact version, which causes troubles for the > developers and which should not be there from the very beginning as we do not > really need some features from this particular version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11105) [TC Bot] Support Teamcity servers aliases
[ https://issues.apache.org/jira/browse/IGNITE-11105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11105: - Fix Version/s: 2.8 > [TC Bot] Support Teamcity servers aliases > - > > Key: IGNITE-11105 > URL: https://issues.apache.org/jira/browse/IGNITE-11105 > Project: Ignite > Issue Type: Task >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Minor > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement feature of aliasing TeamCity builds bat. Alias will act as a > pointer to the real name of a server. > It is necessary for a feature of linking builds with separate JIRA projects > and/or GitHub forks without duplicating of all builds database. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8588) .NET: Serialization issue when derived type hides base type member
[
https://issues.apache.org/jira/browse/IGNITE-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-8588:
Fix Version/s: 2.8
> .NET: Serialization issue when derived type hides base type member
> --
>
> Key: IGNITE-8588
> URL: https://issues.apache.org/jira/browse/IGNITE-8588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The following class structure causes an exception that is hard to understand
> (when putting instance of B into Ignite cache):
> {code}
> public class A
> {
> public int bob;
> }
> public class B : A
> {
> public int bob;
> }
> {code}
> Exception:
> {code}
> Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs
> [type=SubGridsRequestArgument, field1=Filters, field2=Filters,
> fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type,
> BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter
> writer, Object o)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o)
> at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job,
> BinaryWriter writer)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.b__1a(BinaryWriter
> writer)
> at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1
> action, IBinaryStream stream, Marshaller marsh)
> at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
> Action`1 writeAction)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3
> task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount,
> Action`1 writeAction)
> --- End of inner exception stack trace ---
> at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> includeTaskCanceledExceptions)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout,
> CancellationToken cancellationToken)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout)
> at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line
> 107
> at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line
> 241
> at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line
> 262
> ---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException:
> Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters,
> field2=Filters, fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at
[jira] [Updated] (IGNITE-11476) [ML] Use new feature extraction API in examples
[ https://issues.apache.org/jira/browse/IGNITE-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11476: - Fix Version/s: 2.8 > [ML] Use new feature extraction API in examples > --- > > Key: IGNITE-11476 > URL: https://issues.apache.org/jira/browse/IGNITE-11476 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Critical > Labels: stability > Fix For: 2.8 > > > Introduce new feature/label extraction API to all examples. These examples > should work on binary builds without sharing additional jars to libs > directory (except ml-jar). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11053) When cluster is absent Notebook paragraph are supposed to saved.
[ https://issues.apache.org/jira/browse/IGNITE-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11053: - Fix Version/s: 2.8 > When cluster is absent Notebook paragraph are supposed to saved. > > > Key: IGNITE-11053 > URL: https://issues.apache.org/jira/browse/IGNITE-11053 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Original Estimate: 6h > Time Spent: 0.5h > Remaining Estimate: 5.5h > > Currently in scope of task IGNITE-10538 we allow user to use notebooks > screen. But when paragraph is executed notebook is not saved on backend and > no message appears that execution failed. > Error message should be added and notebooks saving on execution should be > made. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-4601) Python: support binary format
[ https://issues.apache.org/jira/browse/IGNITE-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-4601: Fix Version/s: 2.8 > Python: support binary format > - > > Key: IGNITE-4601 > URL: https://issues.apache.org/jira/browse/IGNITE-4601 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis A. Magda >Priority: Major > Fix For: 2.8 > > > Python client has to support binary format natively by implementing a binary > marshaller logic directly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11763) GridP2PComputeWithNestedEntryProcessorTest failed on TC
[
https://issues.apache.org/jira/browse/IGNITE-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11763:
-
Fix Version/s: 2.8
> GridP2PComputeWithNestedEntryProcessorTest failed on TC
> ---
>
> Key: IGNITE-11763
> URL: https://issues.apache.org/jira/browse/IGNITE-11763
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
> Attachments: testContinuousMode, testSharedMode
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Test failed with exception:
> {noformat}
> [2019-04-16 19:50:21,725][ERROR][main][root] Test failed.
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to execute query on node [query=GridCacheQueryBean
> [qry=GridCacheQueryAdapter [type=SCAN, clsName=null, clause=null,
> filter=org.apache.ignite.tests.p2p.pedicates.CompositePredicate@2b939b78,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=true, subjId=008694d2-98a2-4add-9ccc-b7674e6d717f, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=8575809f-3373-4c47-8684-a318c221]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:168)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDistributedQueryManager.java:643)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:123)
> at
> org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.scanByCopositeFirstPredicate(GridP2PComputeWithNestedEntryProcessorTest.java:205)
> at
> org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.scnaCacheData(GridP2PComputeWithNestedEntryProcessorTest.java:188)
> at
> org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.processTest(GridP2PComputeWithNestedEntryProcessorTest.java:140)
> at
> org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.testContinuousMode(GridP2PComputeWithNestedEntryProcessorTest.java:105)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null,
> filter=org.apache.ignite.tests.p2p.pedicates.CompositePredicate@2b939b78,
> transform=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
> sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
> timeout=0, incBackups=false, forceLocal=false, dedup=false, prj=null,
> keepBinary=true, subjId=008694d2-98a2-4add-9ccc-b7674e6d717f, taskHash=0,
> mvccSnapshot=null, dataPageScanEnabled=null], rdc=null, trans=null],
> nodeId=8575809f-3373-4c47-8684-a318c221]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:384)
> at
>
[jira] [Updated] (IGNITE-10519) [TC Bot] Create project documentation
[ https://issues.apache.org/jira/browse/IGNITE-10519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10519: - Fix Version/s: 2.8 > [TC Bot] Create project documentation > - > > Key: IGNITE-10519 > URL: https://issues.apache.org/jira/browse/IGNITE-10519 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Minor > Fix For: 2.8 > > > Fill javadocs and package infos. > Create readme with multiclass interactions for developers with links to > package infos. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7101:
Fix Version/s: 2.8
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Fix For: 2.8
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-529) Implement IgniteFlumeStreamer to stream data from Apache Flume
[
https://issues.apache.org/jira/browse/IGNITE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-529:
---
Fix Version/s: 2.8
> Implement IgniteFlumeStreamer to stream data from Apache Flume
> --
>
> Key: IGNITE-529
> URL: https://issues.apache.org/jira/browse/IGNITE-529
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgniteSinkSetup.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Flume|http://flume.apache.org/] for more information.
> We should create {{IgniteFlumeStreamer}} which will consume messages from
> Apache Flume and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert Flume data to Ignite data using an optional pluggable converter.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-3417) Cassandra packages have no descriptions
[ https://issues.apache.org/jira/browse/IGNITE-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-3417: Fix Version/s: 2.8 > Cassandra packages have no descriptions > --- > > Key: IGNITE-3417 > URL: https://issues.apache.org/jira/browse/IGNITE-3417 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 1.6 >Reporter: Sergey Kozlov >Assignee: Sergey Kozlov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Generated javadoc (overview-summary.html) has no decriptions for Cassandra > package -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling
[
https://issues.apache.org/jira/browse/IGNITE-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11356:
-
Fix Version/s: 2.8
> Test framework: Remove custom assumption exceptions handling
>
>
> Key: IGNITE-11356
> URL: https://issues.apache.org/jira/browse/IGNITE-11356
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It turns out that custom handling of {{AssumptionViolatedException}} can be
> removed. Currently with custom handling tests with unmet assumptions are
> marked as passed. With default handling failed assumptions on instance level
> mark tests as ignored.
> Note: on class level reporting in case of unmet assumptions does not look
> perfect. But with custom handling a particular test is not included into TC
> report at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8014) Node.js client: basic/minimal version
[ https://issues.apache.org/jira/browse/IGNITE-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-8014: Fix Version/s: 2.8 > Node.js client: basic/minimal version > - > > Key: IGNITE-8014 > URL: https://issues.apache.org/jira/browse/IGNITE-8014 > Project: Ignite > Issue Type: Sub-task > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: Alexey Kosenchuk >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Develop the first basic/minimal version - for initial review/feedback. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8757) idle_verify utility doesn't show both update counter and hash conflicts
[ https://issues.apache.org/jira/browse/IGNITE-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-8757: Fix Version/s: 2.8 > idle_verify utility doesn't show both update counter and hash conflicts > --- > > Key: IGNITE-8757 > URL: https://issues.apache.org/jira/browse/IGNITE-8757 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > If there are two partitions in cluster, one with different update counters > and one with different data, idle_verify will show only partition with broken > counters. We should show both for better visibility. > We should also show notify user about rebalancing partitions that were > excluded from analysis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10095) [TC Bot] Support Build Parameters storage in bot's DB and in run statistics
[ https://issues.apache.org/jira/browse/IGNITE-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10095: - Fix Version/s: 2.8 > [TC Bot] Support Build Parameters storage in bot's DB and in run statistics > --- > > Key: IGNITE-10095 > URL: https://issues.apache.org/jira/browse/IGNITE-10095 > Project: Ignite > Issue Type: Task >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > [TC Bot] Support Build Parameters storage in bot's DB, and support > propagation of these parameters into run statistics > It is needed to have a future opportunity to separate Java 8,10,11 Runs and > also runs with short test set and full overnight run. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11181) [TC Bot] Avoid notifications about too old failures
[ https://issues.apache.org/jira/browse/IGNITE-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11181: - Fix Version/s: 2.8 > [TC Bot] Avoid notifications about too old failures > --- > > Key: IGNITE-11181 > URL: https://issues.apache.org/jira/browse/IGNITE-11181 > Project: Ignite > Issue Type: Task >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Fix For: 2.8 > > > Avoid emailing about failures older than some predefined limit -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-2144) [Test] IgniteSemaphore's failover related tests are failing to compile
[ https://issues.apache.org/jira/browse/IGNITE-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-2144: Fix Version/s: 2.8 > [Test] IgniteSemaphore's failover related tests are failing to compile > -- > > Key: IGNITE-2144 > URL: https://issues.apache.org/jira/browse/IGNITE-2144 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Minor > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > GridCacheAbstractDataStructuresFailoverSelfTest are failing to compile. > Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile > (default-testCompile) on project ignite-core: Compilation failure: > Compilation failure: > [ERROR] > /Users/saikat/git/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/datastructures/GridCacheAbstractDataStructuresFailoverSelfTest.java:[458,25] > constructor ConstantTopologyChangeWorker in class > org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.ConstantTopologyChangeWorker > cannot be applied to given types; > [ERROR] required: int > [ERROR] found: no arguments > [ERROR] reason: actual and formal argument lists differ in length > [ERROR] > /Users/saikat/git/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/datastructures/GridCacheAbstractDataStructuresFailoverSelfTest.java:[465,25] > constructor ConstantTopologyChangeWorker in class > org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.ConstantTopologyChangeWorker > cannot be applied to given types; > [ERROR] required: int > [ERROR] found: no arguments > [ERROR] reason: actual and formal argument lists differ in length > [ERROR] > /Users/saikat/git/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/datastructures/GridCacheAbstractDataStructuresFailoverSelfTest.java:[472,25] > method multipleTopologyChangeWorker in class > org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest > cannot be applied to given types; > [ERROR] required: int > [ERROR] found: no arguments > [ERROR] reason: actual and formal argument lists differ in length > [ERROR] > /Users/saikat/git/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/datastructures/GridCacheAbstractDataStructuresFailoverSelfTest.java:[479,25] > method multipleTopologyChangeWorker in class > org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest > cannot be applied to given types; > [ERROR] required: int > [ERROR] found: no arguments > [ERROR] reason: actual and formal argument lists differ in length -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11856) Running ignite.sh with nojmx flag stops with error
[
https://issues.apache.org/jira/browse/IGNITE-11856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11856:
-
Fix Version/s: 2.8
> Running ignite.sh with nojmx flag stops with error
> --
>
> Key: IGNITE-11856
> URL: https://issues.apache.org/jira/browse/IGNITE-11856
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running ignite.sh with the {{-nojmx}} flag results in an error:
> {code:java}
> ./ignite.sh: line 228: JMX_MON: unbound variable{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10533) Web Console: Images outdated on web site.
[ https://issues.apache.org/jira/browse/IGNITE-10533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10533: - Fix Version/s: 2.8 > Web Console: Images outdated on web site. > - > > Key: IGNITE-10533 > URL: https://issues.apache.org/jira/browse/IGNITE-10533 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Kuznetsov >Assignee: Denis A. Magda >Priority: Major > Fix For: 2.8 > > > For example see: https://apacheignite-tools.readme.io/docs/ignite-web-console -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11901) CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11901: - Fix Version/s: 2.8 > CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple is flaky > -- > > Key: IGNITE-11901 > URL: https://issues.apache.org/jira/browse/IGNITE-11901 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple fails on > [TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6927219027805352920=testDetails] > from time to time. It turns out that SCAN query might return incomplete > results on unstable topology. Let's ensure in test that topology is stable > when checks are executed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10980: - Fix Version/s: 2.8 > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > Fix For: 2.8 > > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11760) [TC Bot] Support escaping or replacement of vertical dash in the suite name
[ https://issues.apache.org/jira/browse/IGNITE-11760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11760: - Fix Version/s: 2.8 > [TC Bot] Support escaping or replacement of vertical dash in the suite name > --- > > Key: IGNITE-11760 > URL: https://issues.apache.org/jira/browse/IGNITE-11760 > Project: Ignite > Issue Type: Task >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Usage of same special symbol in JIRA makes TC bot visa unreadable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11779) [TC Bot] Support configurable notifications for non-master branches
[ https://issues.apache.org/jira/browse/IGNITE-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11779: - Fix Version/s: 2.8 > [TC Bot] Support configurable notifications for non-master branches > --- > > Key: IGNITE-11779 > URL: https://issues.apache.org/jira/browse/IGNITE-11779 > Project: Ignite > Issue Type: Task >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Now dev.list notifications performed using fake common user and its settings. > Need to add this rule to branches.json config and support other branches > (e.g. release) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-4602) Python: module and build scripts
[ https://issues.apache.org/jira/browse/IGNITE-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-4602: Fix Version/s: 2.8 > Python: module and build scripts > > > Key: IGNITE-4602 > URL: https://issues.apache.org/jira/browse/IGNITE-4602 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis A. Magda >Priority: Major > Fix For: 2.8 > > > Create "ignite-python" module and implement a build procedure for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11888) CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC
[ https://issues.apache.org/jira/browse/IGNITE-11888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11888: - Fix Version/s: 2.8 > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails on GG TC > -- > > Key: IGNITE-11888 > URL: https://issues.apache.org/jira/browse/IGNITE-11888 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > A test > CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup > fails. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-4774) Web Console: Improve design of tables
[ https://issues.apache.org/jira/browse/IGNITE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-4774: Fix Version/s: 2.8 > Web Console: Improve design of tables > - > > Key: IGNITE-4774 > URL: https://issues.apache.org/jira/browse/IGNITE-4774 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Tables should be adaptive. > The height of the lines should be bigger. > Buttons need to be more obvious. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12168) [ML] Flaky ML example tests
[ https://issues.apache.org/jira/browse/IGNITE-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12168: - Fix Version/s: 2.8 > [ML] Flaky ML example tests > --- > > Key: IGNITE-12168 > URL: https://issues.apache.org/jira/browse/IGNITE-12168 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Discussed here > [http://apache-ignite-developers.2346864.n4.nabble.com/After-IGNITE-12148-the-Examples-suite-has-unstable-tests-td43469.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11690) .NET: Unable to locate external assembly with enabled peerAssemblyLoading
[ https://issues.apache.org/jira/browse/IGNITE-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11690: - Fix Version/s: 2.8 > .NET: Unable to locate external assembly with enabled peerAssemblyLoading > -- > > Key: IGNITE-11690 > URL: https://issues.apache.org/jira/browse/IGNITE-11690 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > Original reproducer: > [https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0] With > two server nodes, and a client that spawn a computation with a simple cache > iteration for custom class value > Problem: > If peer assembly loading enabled and no assembly exist for the nodes, then > there is an endless loop: nodes are requesting the assembly from each other > and no one is able to locate it. > As an example of missing dll there could be a > "System.Configuration.Configuration" for the .NET Core app > [https://github.com/dotnet/standard/issues/506] > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11757) Missed partitions during rebalancing when new blank node joins
[ https://issues.apache.org/jira/browse/IGNITE-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11757: - Fix Version/s: 2.8 > Missed partitions during rebalancing when new blank node joins > -- > > Key: IGNITE-11757 > URL: https://issues.apache.org/jira/browse/IGNITE-11757 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ilya Kasnacheev >Assignee: Vladislav Pyatkov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Please take a look at newly added test > GridCachePartitionedSupplyEventsSelfTest.testSupplyEvents > There's logging of missed partitions during rebalancing, and as you can see > partitions are missed even when a new node joins stable topology, with no > nodes leaving. > Expected behavior is that in this case no partitions will be missed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9876) .NET: Thin Client: Implement Best Effort Affinity
[ https://issues.apache.org/jira/browse/IGNITE-9876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9876: Fix Version/s: 2.8 > .NET: Thin Client: Implement Best Effort Affinity > - > > Key: IGNITE-9876 > URL: https://issues.apache.org/jira/browse/IGNITE-9876 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-23 > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > See linked IEP-23. > First iteration is going to be an "experimental feature" with the following > limitations: > * No reconnect support for failed nodes > * No AffinityKeyMapped support -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11654) ML: Memory leak in KNNClassificationModel
[ https://issues.apache.org/jira/browse/IGNITE-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11654: - Fix Version/s: 2.8 > ML: Memory leak in KNNClassificationModel > - > > Key: IGNITE-11654 > URL: https://issues.apache.org/jira/browse/IGNITE-11654 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > KNNClassificationModel acquires datasets which keeps resources within the > cluster, but doesn't close it. As result of that we have a memory leak > because resources allocated for dataset are not collected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7226) Web console: Notification placeholder on empty user table
[ https://issues.apache.org/jira/browse/IGNITE-7226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7226: Fix Version/s: 2.8 > Web console: Notification placeholder on empty user table > - > > Key: IGNITE-7226 > URL: https://issues.apache.org/jira/browse/IGNITE-7226 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexander Kalinin >Priority: Major > Fix For: 2.8 > > > # Open Admin panel > # Filter all data in table. > Table showed without data and any information message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12010) [TC Bot] Consider newly contributed test as blocker if it runs more that 1 minute.
[ https://issues.apache.org/jira/browse/IGNITE-12010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12010: - Fix Version/s: 2.8 > [TC Bot] Consider newly contributed test as blocker if it runs more that 1 > minute. > -- > > Key: IGNITE-12010 > URL: https://issues.apache.org/jira/browse/IGNITE-12010 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Long-running tests should be scaled by the scale factor, and/or moved to Run > All nightly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11655) ML: OneHotEncoder returns more columns than expected
[
https://issues.apache.org/jira/browse/IGNITE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11655:
-
Fix Version/s: 2.8
> ML: OneHotEncoder returns more columns than expected
>
>
> Key: IGNITE-11655
> URL: https://issues.apache.org/jira/browse/IGNITE-11655
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Assignee: Alexey Zinoviev
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> OneHotEncoder returns more columns than expected (two values that might be
> encoded using two columns encoded using 3 columns). The following example
> demonstrates the problem:
> {code:java}
> Map training = new HashMap<>();
> training.put(0, new Object[]{42.0});
> training.put(1, new Object[]{43.0});
> training.put(2, new Object[]{42.0});
> EncoderTrainer trainer = new EncoderTrainer Object[]>()
> .withEncoderType(EncoderType.ONE_HOT_ENCODER)
> .withEncodedFeature(0);
> IgniteBiFunction processor = trainer.fit(training,
> 1, (k, v) -> v);
> Vector res = processor.apply(1, new Object[]{42.0});
> System.out.println(Arrays.toString(res.asArray()));
> >>> [0.0, 1.0, 0.0]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10302) MVCC: Update backups asynchronously
[ https://issues.apache.org/jira/browse/IGNITE-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10302: - Fix Version/s: 2.8 > 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 >Priority: Major > Fix For: 2.8 > > > 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 (v8.3.4#803005)
[jira] [Updated] (IGNITE-12166) .NET: ExecutableTest fails with PathTooLong error
[ https://issues.apache.org/jira/browse/IGNITE-12166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12166: - Fix Version/s: 2.8 > .NET: ExecutableTest fails with PathTooLong error > - > > Key: IGNITE-12166 > URL: https://issues.apache.org/jira/browse/IGNITE-12166 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.8 > > > When repo root path is long enough, it causes ExecutableTests to fail - > classpath exceeds Win32 limit of 32767 characters. If fact, we don't need to > pass classpath explicitly to IgniteProcess. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11895) .NET Resharper inspections got broken after update
[ https://issues.apache.org/jira/browse/IGNITE-11895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11895: - Fix Version/s: 2.8 > .NET Resharper inspections got broken after update > -- > > Key: IGNITE-11895 > URL: https://issues.apache.org/jira/browse/IGNITE-11895 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.7 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Resharper Inspection add new violation after migration from 2018.1.4 to > version 2019.1 > Lets suppress this new warning -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11778) [TC Bot] Implement unconditional blockers and add license check suites to blockers
[ https://issues.apache.org/jira/browse/IGNITE-11778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11778: - Fix Version/s: 2.8 > [TC Bot] Implement unconditional blockers and add license check suites to > blockers > -- > > Key: IGNITE-11778 > URL: https://issues.apache.org/jira/browse/IGNITE-11778 > Project: Ignite > Issue Type: Task >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Minor > Fix For: 2.8 > > > License by RAT plugin validation should be also > - considered as a blocker in PR validation > - introduced failure should cause notification on tracked branches -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11947) [TC Bot] New failures notification are absent for several new failures
[ https://issues.apache.org/jira/browse/IGNITE-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11947: - Fix Version/s: 2.8 > [TC Bot] New failures notification are absent for several new failures > -- > > Key: IGNITE-11947 > URL: https://issues.apache.org/jira/browse/IGNITE-11947 > Project: Ignite > Issue Type: Bug >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Fix For: 2.8 > > > Notifications to email are missed sometimes. > One possible reason is buildStartTs, which was not filled correctly in Issue, > but after fix > https://github.com/apache/ignite-teamcity-bot/commit/5573467d04eedbe9f79dd2b19e9675b76af78985 > the situation is still the same, notifications not send -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9677) [TC Bot] Automatic build trigger should track all branches defined in configuration.
[
https://issues.apache.org/jira/browse/IGNITE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9677:
Fix Version/s: 2.8
> [TC Bot] Automatic build trigger should track all branches defined in
> configuration.
>
>
> Key: IGNITE-9677
> URL: https://issues.apache.org/jira/browse/IGNITE-9677
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Dmitry Pavlov
>Priority: Major
> Fix For: 2.8
>
>
> Automatic build trigger tracks only chains defined in branch with identifier
> "master", this should be changed to track all configured branches.
> Also before bot starts build it checks that there is no self-started builds
> in queue already, this check should be improved to be able start another
> branch build simultaneously (skip triggering only if build's {{branchName}}
> is equal to {{branchForRest}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12205) GridCachePartitionedSetWithClientSelfTest.testMultithreaded has 95,5% fail rate for long time
[ https://issues.apache.org/jira/browse/IGNITE-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12205: - Fix Version/s: 2.8 > GridCachePartitionedSetWithClientSelfTest.testMultithreaded has 95,5% fail > rate for long time > - > > Key: IGNITE-12205 > URL: https://issues.apache.org/jira/browse/IGNITE-12205 > Project: Ignite > Issue Type: Bug >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > This is well-know failure, need to investigate and fix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7382) Unknown Pair exception if work directory is removed after cluster shutdown
[
https://issues.apache.org/jira/browse/IGNITE-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7382:
Fix Version/s: 2.8
> Unknown Pair exception if work directory is removed after cluster shutdown
> --
>
> Key: IGNITE-7382
> URL: https://issues.apache.org/jira/browse/IGNITE-7382
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: RHEL 7.4
> Docker
>Reporter: Sunny Chan
>Priority: Major
> Fix For: 2.8
>
>
> To reproduce, try this:
> 1) Start a server node
> 2) Start a node in client mode, connect to server node
> 3) shutdown the server node and _leave the client node running_
> 4) remove Ignite work directory for the shutdown server node
> 5) Client node reconnects automatically, send a service call request
> 6) Exception occurs on Server, unable to deserialize
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2
> {noformat}
> 2018-01-05 00:00:26.027 processors.job.GridJobWorker [svc-#273%clog%] ERROR -
> Failed to initialize job
> [jobId=839fef0c061-ad77f485-d677-4694-8d0c-e780f16be9b7,
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl [taskName=o.a.i.i.processors.
> service.GridServiceProxy$ServiceProxyCallable, dep=LocalDeployment
> [super=GridDeployment [ts=1515076515280, depMode=SHARED,
> clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> clsLdrId=3e4f891c061-5235b03b-87c3-4c29-a576-1b44936b0c11, user
> Ver=0, loc=true, sampleClsName=java.lang.String, pendingUndeploy=false,
> undeployed=false, usage=0]],
> taskClsName=o.a.i.i.processors.service.GridServiceProxy$ServiceProxyCallable,
> sesId=739fef0c061-ad77f485-d677-4694-8d0c-e780f16be9b7, st
> artTime=1515078026015, endTime=1515078036021,
> taskNodeId=ad77f485-d677-4694-8d0c-e780f16be9b7,
> clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6, closed=false, cpSpi=null,
> failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=false
> , subjId=ad77f485-d677-4694-8d0c-e780f16be9b7, mapFut=IgniteFuture
> [orig=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
> hash=360535376]], execName=null],
> jobId=839fef0c061-ad77f485-d677-4694-8d0c-e780f16be9b7]]
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2]
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9859)
> [logic.jar:1.1.0]
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:438)
> [logic.jar:1.1.0]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1109)
> [logic.jar:1.1.0]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1913)
> [logic.jar:1.1.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
> [logic.jar:1.1.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
> [logic.jar:1.1.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [logic.jar:1.1.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
> [logic.jar:1.1.0]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_121]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]
> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to
> deserialize object
> [typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
> ~[logic.jar:1.1.0]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> ~[logic.jar:1.1.0]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> ~[logic.jar:1.1.0]
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
> ~[logic.jar:1.1.0]
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
> ~[logic.jar:1.1.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> ~[logic.jar:1.1.0]
> at
>
[jira] [Updated] (IGNITE-2123) Need to add EntryProcessorExample to cache examples
[
https://issues.apache.org/jira/browse/IGNITE-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-2123:
Fix Version/s: 2.8
> Need to add EntryProcessorExample to cache examples
> ---
>
> Key: IGNITE-2123
> URL: https://issues.apache.org/jira/browse/IGNITE-2123
> Project: Ignite
> Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Roman Shtykh
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> One can take {{CacheAffinityExample}} as an example.
> # call entry processors in a loop, if entry is null then create it in entry
> processor
> # do gets in a loop and show that entries are in cache
> # call entry processors in a loop and modify existing entries
> # do gets in a loop and show the results of modification
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
