[jira] [Commented] (IGNITE-9429) GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607878#comment-16607878
]
Pavel Pereslegin commented on IGNITE-9429:
--
[~agoncharuk], seems we can miss some bugs with catching
IllegalStateException for all datastructures. I see only one problem
in this test - {{G.allGrids()}} returns unordered list, so we should
change:
{code:java}
if (circular)
stopGrid(G.allGrids().get(0).configuration().getIgniteInstanceName());
{code}
to
{code:java}
if (circular)
stopGrid(idx - gridCount());
{code}
This will fix flaky failures and preserves the idea of "circular" node stopping.
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> is flaky
> ---
>
> Key: IGNITE-9429
> URL: https://issues.apache.org/jira/browse/IGNITE-9429
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test fails with various exception, I see several issues:
> 1) Atomic structure is accessed during a node stop, which leads to
> NodeStoppingException (should be ignored)
> 2) Same race which leads to IllegalStateException: node is stopped
> 3) Invalid atomic integer increment which rarely leads to "Ignite instance
> with the same name has already been started" exception
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9429) GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9429:
-
Comment: was deleted
(was: [~agoncharuk], seems we can miss some bugs with catching
IllegalStateException for all datastructures. I see only one problem
in this test - {{G.allGrids()}} returns unordered list now, so we should
change:
{code:java}
if (circular)
stopGrid(G.allGrids().get(0).configuration().getIgniteInstanceName());
{code}
to
{code:java}
if (circular)
stopGrid(i);
{code}
This will fix flaky failures and preserves the idea of "circular" node
stopping.)
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> is flaky
> ---
>
> Key: IGNITE-9429
> URL: https://issues.apache.org/jira/browse/IGNITE-9429
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test fails with various exception, I see several issues:
> 1) Atomic structure is accessed during a node stop, which leads to
> NodeStoppingException (should be ignored)
> 2) Same race which leads to IllegalStateException: node is stopped
> 3) Invalid atomic integer increment which rarely leads to "Ignite instance
> with the same name has already been started" exception
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9484) MVCC TX: Handling transactions from multiple threads in jdbc requests handler.
[ https://issues.apache.org/jira/browse/IGNITE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-9484: - Description: Currently JDBC/ODBC requests are handled in NioWorker threads; that means what sessions may be rebalanced between nio threads which makes impossible to associate a NearTransaction with caller thread. There are two possible solutions: # To process client messages like regular grid ones in separate thread pool in thread-per-connection basis # Implement Suspend/Resume functionality for pessimistic transactions like it was done for optimistic ones (only pessimistic transactions are supported by mvcc-enabled caches) was: Currently JDBC/ODBC requests are handled in NioWorker threads; that means what sessions may be rebalanced between nio threads which makes impossible to associate a NearTransaction with caller thread. There are two possible solutions: # To process client messages like regular grid ones in separate thread pool in thread-per-connection basis # Implement Suspend/Resume functionality for pessimistic transactions as well as for optimistic ones (only pessimistic transactions are supported by mvcc-enabled caches) > MVCC TX: Handling transactions from multiple threads in jdbc requests handler. > -- > > Key: IGNITE-9484 > URL: https://issues.apache.org/jira/browse/IGNITE-9484 > Project: Ignite > Issue Type: Task > Components: jdbc, mvcc >Reporter: Roman Kondakov >Priority: Major > > Currently JDBC/ODBC requests are handled in NioWorker threads; that means > what sessions may be rebalanced between nio threads which makes impossible to > associate a NearTransaction with caller thread. > There are two possible solutions: > # To process client messages like regular grid ones in separate thread pool > in thread-per-connection basis > # Implement Suspend/Resume functionality for pessimistic transactions like > it was done for optimistic ones (only pessimistic transactions are supported > by mvcc-enabled caches) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9484) MVCC TX: Handling transactions from multiple threads in jdbc requests handler.
[
https://issues.apache.org/jira/browse/IGNITE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-9484:
-
Description:
Currently JDBC/ODBC requests are handled in NioWorker threads; that means what
sessions may be rebalanced between nio threads which makes impossible to
associate a NearTransaction with caller thread.
There are two possible solutions:
# To process client messages like regular grid ones in separate thread pool in
thread-per-connection basis
# Implement Suspend/Resume functionality for pessimistic transactions as well
as for optimistic ones (only pessimistic transactions are supported by
mvcc-enabled caches)
was:
JDBC requests may be handled by the different threads of thread pool even if
they belong to the same transaction. As a workaround a dedicated worker thread
is created for each session, which is not the best solution.
it is much better to have an abiltity to drive {{Near}} transactions from
different threads in the cases when transaction actions are applied
sequentially.
> MVCC TX: Handling transactions from multiple threads in jdbc requests handler.
> --
>
> Key: IGNITE-9484
> URL: https://issues.apache.org/jira/browse/IGNITE-9484
> Project: Ignite
> Issue Type: Task
> Components: jdbc, mvcc
>Reporter: Roman Kondakov
>Priority: Major
>
> Currently JDBC/ODBC requests are handled in NioWorker threads; that means
> what sessions may be rebalanced between nio threads which makes impossible to
> associate a NearTransaction with caller thread.
> There are two possible solutions:
> # To process client messages like regular grid ones in separate thread pool
> in thread-per-connection basis
> # Implement Suspend/Resume functionality for pessimistic transactions as
> well as for optimistic ones (only pessimistic transactions are supported by
> mvcc-enabled caches)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9429) GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607528#comment-16607528
]
Pavel Pereslegin commented on IGNITE-9429:
--
[~agoncharuk], seems we can miss some bugs with catching
IllegalStateException for all datastructures. I see only one problem
in this test - {{G.allGrids()}} returns unordered list now, so we should
change:
{code:java}
if (circular)
stopGrid(G.allGrids().get(0).configuration().getIgniteInstanceName());
{code}
to
{code:java}
if (circular)
stopGrid(i);
{code}
This will fix flaky failures and preserves the idea of "circular" node stopping.
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> is flaky
> ---
>
> Key: IGNITE-9429
> URL: https://issues.apache.org/jira/browse/IGNITE-9429
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test fails with various exception, I see several issues:
> 1) Atomic structure is accessed during a node stop, which leads to
> NodeStoppingException (should be ignored)
> 2) Same race which leads to IllegalStateException: node is stopped
> 3) Invalid atomic integer increment which rarely leads to "Ignite instance
> with the same name has already been started" exception
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9501) Exclude newly joining nodes from exchange latch
Pavel Kovalenko created IGNITE-9501: --- Summary: Exclude newly joining nodes from exchange latch Key: IGNITE-9501 URL: https://issues.apache.org/jira/browse/IGNITE-9501 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.7 Currently, we're waiting for latch completion from newly joining nodes. However, such nodes don't have any updates to be synced on wait partitions release. Newly joining nodes may start their caches before exchange latch creation and this can delay exchange process. We should explicitly ignore such nodes and don't include them into latch participants. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9091) IEP-25: creating documentation
[ https://issues.apache.org/jira/browse/IGNITE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov updated IGNITE-9091: --- Fix Version/s: 2.7 > IEP-25: creating documentation > -- > > Key: IGNITE-9091 > URL: https://issues.apache.org/jira/browse/IGNITE-9091 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alex Volkov >Assignee: Artem Budnikov >Priority: Major > Labels: iep-25 > Fix For: 2.7 > > > It would be great to have proper documentation for IEP-25: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-25:+Partition+Map+Exchange+hangs+resolving] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4221) Document ComputeJobMasterLeaveAware interface usage
[ https://issues.apache.org/jira/browse/IGNITE-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4221: Fix Version/s: (was: 2.7) 2.8 > Document ComputeJobMasterLeaveAware interface usage > --- > > Key: IGNITE-4221 > URL: https://issues.apache.org/jira/browse/IGNITE-4221 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > The usage and applicability of `ComputeJobMasterLeaveAware` have to be > documented on Apache Ignite Readme.io which will help out to avoid discussion > like that [1]. The new page has to be created for the topic and placed here > [2]. > In advance, the following example has to be contributed to Apache Ignite > https://github.com/gridgain/gridgain-advanced-examples/blob/master/src/main/java/org/gridgain/examples/compute/masterleave/ComputeMasterLeaveAwareExample.java > > [1] > http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html > [2] https://apacheignite.readme.io/docs/compute-grid#section-features -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-2769) Document store session listeners
[ https://issues.apache.org/jira/browse/IGNITE-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2769: Fix Version/s: (was: 2.7) 2.8 > Document store session listeners > > > Key: IGNITE-2769 > URL: https://issues.apache.org/jira/browse/IGNITE-2769 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4222) Document the usage of ComputeJobContinuation API
[ https://issues.apache.org/jira/browse/IGNITE-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4222: Fix Version/s: (was: 2.7) 2.8 > Document the usage of ComputeJobContinuation API > > > Key: IGNITE-4222 > URL: https://issues.apache.org/jira/browse/IGNITE-4222 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > The usage and applicability of `ComputeJobContinuation` have to be documented > on Apache Ignite Readme.io which will help out to avoid discussion like those > [1] and [4]. The new page has to be created for the topic and placed here [2]. > The content should consist not only of technical details but also provide use > cases for this API: > - don't block a thread from the public pool if a job is waiting for some > result. Put the thread back into the pool and wait for the result > asynchronously. > - splitting a job into several pieces that can be executed in parallel. Refer > to this example [3]. > > [1] > http://apache-ignite-users.70518.x6.nabble.com/Remote-Server-Thread-Not-exit-when-Job-finished-Cause-out-of-memory-tp8934p8947.html > [2] https://apacheignite.readme.io/docs/compute-grid#section-features > [3] > https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/computegrid/ComputeFibonacciContinuationExample.java > [4] > http://apache-ignite-users.70518.x6.nabble.com/ignite-compute-job-continuation-documentation-td16725.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4718) Add section in documentation on what actions may cause deadlock
[ https://issues.apache.org/jira/browse/IGNITE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4718: Fix Version/s: (was: 2.7) 2.8 > Add section in documentation on what actions may cause deadlock > --- > > Key: IGNITE-4718 > URL: https://issues.apache.org/jira/browse/IGNITE-4718 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 1.8 >Reporter: Dmitry Karachentsev >Priority: Minor > Fix For: 2.8 > > > Ignite has number of common cases, where wrong usage of API may lead to > deadlocks, starvations, cluster hangs, and they should be properly > documented. > For example, cache operations is not allowed in CacheEntryProcessor, > ContinuousQuery's remote filter, etc. And in some callbacks it's possible to > use cache API if they annotated with @IgniteAsyncCallback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9500) SQL system view for list of caches
Aleksey Plekhanov created IGNITE-9500: - Summary: SQL system view for list of caches Key: IGNITE-9500 URL: https://issues.apache.org/jira/browse/IGNITE-9500 Project: Ignite Issue Type: Task Components: sql Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Implement SQL system view to show list of caches with basic cache information (name, cache group, atomicity mode, cache mode, data region) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3690) Log Message Glossary
[ https://issues.apache.org/jira/browse/IGNITE-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3690: Fix Version/s: (was: 2.7) 2.8 > Log Message Glossary > > > Key: IGNITE-3690 > URL: https://issues.apache.org/jira/browse/IGNITE-3690 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 1.4 >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.8 > > > It's time for Ignite to create a page which lists ALL the log messages, their > common causes and potential solutions. > Probably it makes sense to assign an unique ID for the most well-know errors > so that a user is able to look up an error in the glossary quicker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5922) Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than PublicThreadPoolSize
[ https://issues.apache.org/jira/browse/IGNITE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-5922: --- Assignee: Prachi Garg (was: Evgenii Zhuravlev) > Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than > PublicThreadPoolSize > -- > > Key: IGNITE-5922 > URL: https://issues.apache.org/jira/browse/IGNITE-5922 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Prachi Garg >Priority: Minor > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6501) select distinct exception in simple sqlQuery request.
[
https://issues.apache.org/jira/browse/IGNITE-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-6501:
---
Assignee: Artem Budnikov (was: Vladimir Ozerov)
> select distinct exception in simple sqlQuery request.
> -
>
> Key: IGNITE-6501
> URL: https://issues.apache.org/jira/browse/IGNITE-6501
> Project: Ignite
> Issue Type: Bug
> Components: documentation, sql
>Affects Versions: 2.0, 2.1
>Reporter: Stanilovsky Evgeny
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
> Attachments: DistinctTest.java
>
>
> SqlQuery throws exception
> {code}
> Failed to parse query: SELECT distinct Value._KEY, distinct Value._VAL from
> Value
> {code}
> while SqlFieldsQuery works properly well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5922) Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than PublicThreadPoolSize
[ https://issues.apache.org/jira/browse/IGNITE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-5922: Fix Version/s: (was: 2.7) 2.8 > Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than > PublicThreadPoolSize > -- > > Key: IGNITE-5922 > URL: https://issues.apache.org/jira/browse/IGNITE-5922 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Minor > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5678) Need to document and test supported and unsupported SQL features
[ https://issues.apache.org/jira/browse/IGNITE-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-5678: Fix Version/s: (was: 2.7) 2.8 > Need to document and test supported and unsupported SQL features > > > Key: IGNITE-5678 > URL: https://issues.apache.org/jira/browse/IGNITE-5678 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Dmitriy Setrakyan >Assignee: Sergey Kozlov >Priority: Major > Fix For: 2.8 > > > We should provide supported and unsupported feature documentation, similar to > PostgreSQL: https://www.postgresql.org/docs/devel/static/features.html > We can do the following: > * Have a very detailed documented list of all the supported/unsupported > features in Ignite SQL engine. > * Once the list is created, ensure that we have sufficient test coverage for > all the supported features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6716) Document "Affinity key backups mismatch" resolution steps
[
https://issues.apache.org/jira/browse/IGNITE-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6716:
Fix Version/s: (was: 2.7)
2.8
> Document "Affinity key backups mismatch" resolution steps
> -
>
> Key: IGNITE-6716
> URL: https://issues.apache.org/jira/browse/IGNITE-6716
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Nicholas DiPiazza
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.8
>
>
> Please see the issue below:
> https://stackoverflow.com/questions/46894435/how-do-i-fix-affinity-key-backups-in-cache-configuration
> results in this error:
> {code}
> org.apache.ignite.IgniteCheckedException: Affinity key backups mismatch (fix
> affinity key backups in cache configuration or set
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property)
> {code}
> Can someone help me get the steps in order to fix this issue? we should add
> it to the documentation somewhere.
> # What causes this error?
> # How to fix this error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6784) Document cluster activation via REST protocol
[
https://issues.apache.org/jira/browse/IGNITE-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6784:
Fix Version/s: (was: 2.7)
2.8
> Document cluster activation via REST protocol
> -
>
> Key: IGNITE-6784
> URL: https://issues.apache.org/jira/browse/IGNITE-6784
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.4
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.8
>
>
> Starting Ignite 2.3 cluster can be activated with REST protocol. The
> following commands are supported:
> - {{activate}} - actives the cluster.
> - {{deactivate}} - deactivates the cluster.
> - {{currentstate}} - checks current cluster state.
> Update both pages below:
> https://apacheignite.readme.io/docs/rest-api
> https://apacheignite.readme.io/v2.2/docs/cluster-activation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-6526) Ignite 2.x capacity planning guide
[ https://issues.apache.org/jira/browse/IGNITE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-6526: --- Assignee: Denis Magda > Ignite 2.x capacity planning guide > -- > > Key: IGNITE-6526 > URL: https://issues.apache.org/jira/browse/IGNITE-6526 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Minor > Fix For: 2.7 > > > Current capacity planning guide [1] is too high level and should be > elaborated considering durable memory's internals: > - memory pages overhead. > - per-entry overhead > (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html). > - space occupied for indexing needs. > - free lists > - etc. > The page has to include estimates for the Ignite Native Persistence: > - entry size and its overheads. > - index size and overheads. > - data files overheads. > - estimated WAL size and how to shrink it basing on checkpointing settings. > [1] https://apacheignite.readme.io/docs/capacity-planning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6993) Document SMTP server documentation for Web Console
[ https://issues.apache.org/jira/browse/IGNITE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-6993: --- Assignee: Artem Budnikov (was: Alexey Kuznetsov) > Document SMTP server documentation for Web Console > -- > > Key: IGNITE-6993 > URL: https://issues.apache.org/jira/browse/IGNITE-6993 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > > Document how to configure a custom SMTP server for Web Console on this domain > under "Ignite Web Console" section: > https://apacheignite-tools.readme.io/docs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6953) OOM on the client node freezes the whole cluster
[ https://issues.apache.org/jira/browse/IGNITE-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-6953. --- > OOM on the client node freezes the whole cluster > > > Key: IGNITE-6953 > URL: https://issues.apache.org/jira/browse/IGNITE-6953 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Denis Magda >Priority: Major > Labels: iep-5 > Fix For: 2.7 > > Attachments: OOMETest.java, ignite-0590a557.log, ignite-5df99d7b.log, > ignite-9b5b6e6e.log > > > It's reported that if an OOM happens on the client side the whole cluster > becomes unresponsive: > http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html > Let's reproduce and prevent this by bringing the client node down > automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6806) Document logs forwarding to ELK stack
[ https://issues.apache.org/jira/browse/IGNITE-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6806: Fix Version/s: (was: 2.7) 2.8 > Document logs forwarding to ELK stack > - > > Key: IGNITE-6806 > URL: https://issues.apache.org/jira/browse/IGNITE-6806 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > Ignite logs can be forwarded to remote servers and software stacks for > advanced processing. > For instance, this project shows how to do this for ELK stack: > https://github.com/akuramshingg/elk-monitor > Mention it on Ignite logging page: > https://apacheignite.readme.io/docs/logging -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6953) OOM on the client node freezes the whole cluster
[ https://issues.apache.org/jira/browse/IGNITE-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-6953. - Resolution: Won't Fix > OOM on the client node freezes the whole cluster > > > Key: IGNITE-6953 > URL: https://issues.apache.org/jira/browse/IGNITE-6953 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Denis Magda >Priority: Major > Labels: iep-5 > Fix For: 2.7 > > Attachments: OOMETest.java, ignite-0590a557.log, ignite-5df99d7b.log, > ignite-9b5b6e6e.log > > > It's reported that if an OOM happens on the client side the whole cluster > becomes unresponsive: > http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html > Let's reproduce and prevent this by bringing the client node down > automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7131) Document Web Console deployment in Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7131: --- Assignee: Denis Magda (was: Artem Budnikov) > Document Web Console deployment in Kubernetes > - > > Key: IGNITE-7131 > URL: https://issues.apache.org/jira/browse/IGNITE-7131 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.5 >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > The ticket is inspired by the following topic: > http://apache-ignite-users.70518.x6.nabble.com/Web-Console-on-Kubernetes-Cluster-td18591.html > It will be great to put together a documentation about Web Console deployment > on Kubernetes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6993) Document SMTP server documentation for Web Console
[ https://issues.apache.org/jira/browse/IGNITE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6993: Fix Version/s: (was: 2.7) 2.8 > Document SMTP server documentation for Web Console > -- > > Key: IGNITE-6993 > URL: https://issues.apache.org/jira/browse/IGNITE-6993 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Denis Magda >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Document how to configure a custom SMTP server for Web Console on this domain > under "Ignite Web Console" section: > https://apacheignite-tools.readme.io/docs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7131) Document Web Console deployment in Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607265#comment-16607265 ] Denis Magda commented on IGNITE-7131: - Ready: I'll review it: https://apacheignite-tools.readme.io/docs/kubernetes-installation > Document Web Console deployment in Kubernetes > - > > Key: IGNITE-7131 > URL: https://issues.apache.org/jira/browse/IGNITE-7131 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.5 >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > The ticket is inspired by the following topic: > http://apache-ignite-users.70518.x6.nabble.com/Web-Console-on-Kubernetes-Cluster-td18591.html > It will be great to put together a documentation about Web Console deployment > on Kubernetes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7131) Document Web Console deployment in Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7131: --- Assignee: Artem Budnikov (was: Roman Guseinov) > Document Web Console deployment in Kubernetes > - > > Key: IGNITE-7131 > URL: https://issues.apache.org/jira/browse/IGNITE-7131 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.5 >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > The ticket is inspired by the following topic: > http://apache-ignite-users.70518.x6.nabble.com/Web-Console-on-Kubernetes-Cluster-td18591.html > It will be great to put together a documentation about Web Console deployment > on Kubernetes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7132) Investigate and document Ignite Persistence usage in Docker
[ https://issues.apache.org/jira/browse/IGNITE-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7132: Fix Version/s: (was: 2.7) 2.8 > Investigate and document Ignite Persistence usage in Docker > --- > > Key: IGNITE-7132 > URL: https://issues.apache.org/jira/browse/IGNITE-7132 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.8 > > > Inspired by the following talk: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-in-docker-Native-Persistence-td18426.html > The aim is to investigate how is better to deploy Ignite persistence in > Docker. Probably with the usage of Docker volumes: > https://docs.docker.com/engine/admin/volumes/volumes/#use-a-read-only-volume > Once the configuration option is clear the following documentation needs to > be updated: > https://apacheignite.readme.io/docs/docker-deployment -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7336) Improve peer class loading documentation
[ https://issues.apache.org/jira/browse/IGNITE-7336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7336: Fix Version/s: (was: 2.7) 2.8 > Improve peer class loading documentation > > > Key: IGNITE-7336 > URL: https://issues.apache.org/jira/browse/IGNITE-7336 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > [Zero Deployment|https://apacheignite.readme.io/docs/zero-deployment] page > should be updated with the following: > * Applicability of the feature (where it can and can't be used). > * Warning about anonymous classes and lambdas. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7268) SQL Tutorials Per Language
[ https://issues.apache.org/jira/browse/IGNITE-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7268: Fix Version/s: (was: 2.7) 2.8 > SQL Tutorials Per Language > -- > > Key: IGNITE-7268 > URL: https://issues.apache.org/jira/browse/IGNITE-7268 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Priority: Major > Fix For: 2.8 > > > Create SQL getting started tutorials for major programming languages relying > on JDBC/ODBC drivers. Have Spanner's tutorials in mind as an example: > https://cloud.google.com/spanner/docs/getting-started/nodejs/ > This is an umbrella ticket. Language-specific tutorials will be handled as > subtasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7525) ODBC: Add a note about connection non-thread safety to docs
[ https://issues.apache.org/jira/browse/IGNITE-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607261#comment-16607261 ] Denis Magda commented on IGNITE-7525: - [~pgarg], please work with Igor to get this documented. > ODBC: Add a note about connection non-thread safety to docs > --- > > Key: IGNITE-7525 > URL: https://issues.apache.org/jira/browse/IGNITE-7525 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Our ODBC connection is not thread safe. Let's mention it in docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7555) Create documentation for using Ignite Persistence on Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-7555. --- > Create documentation for using Ignite Persistence on Kubernetes > --- > > Key: IGNITE-7555 > URL: https://issues.apache.org/jira/browse/IGNITE-7555 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7555) Create documentation for using Ignite Persistence on Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-7555. - Resolution: Fixed Done. The anchor page is https://apacheignite.readme.io/docs/kubernetes-deployment > Create documentation for using Ignite Persistence on Kubernetes > --- > > Key: IGNITE-7555 > URL: https://issues.apache.org/jira/browse/IGNITE-7555 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Evgenii Zhuravlev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7595: --- Assignee: Denis Magda (was: Prachi Garg) > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.8 > > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7595: Fix Version/s: (was: 2.7) 2.8 > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.8 > > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7711) Explain the case-sensitivity of schema and table/cache
[
https://issues.apache.org/jira/browse/IGNITE-7711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda closed IGNITE-7711.
---
> Explain the case-sensitivity of schema and table/cache
> --
>
> Key: IGNITE-7711
> URL: https://issues.apache.org/jira/browse/IGNITE-7711
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Magda
>Priority: Major
> Fix For: 2.7
>
>
> Users don't get how to use table and schema name in Ignite:
> [https://stackoverflow.com/questions/48723946/apache-ignite-querying-a-cache-through-an-sql-driver]
> The confusion comes from the interpretation of term "case-insensitive". All
> SQL databases work this way:
>
> 1) If I create some object and define its name without quotes, a database
> will convert it to upper case (sometimes lower case). Then if I query this
> object without quotes, a query is also transformed to upper case. This is
> what I call "case-insensitivity" - it doesn't matter how you refer to this
> object, it works still.
> CREATE TABLE myTable -> CREATE TABLE MYTABLE
> SELECT FROM myTable -> SELECT FROM MYTABLE -> OK
> SELECT FROM MyTable -> SELECT FROM MYTABLE -> OK
> SELECT FROM "myTable" -> SELECT FROM myTable -> *{color:#ff}FAIL!{color}*
>
> 2) If I create an object with quotes, then the database doesn't convert it to
> upper case, and the original name in quotes is *the only way* to access the
> object:
> CREATE TABLE "myTable" -> CREATE TABLE myTable
> SELECT FROM myTable -> SELECT FROM MYTABLE -> *{color:#ff}FAIL!{color}*
> SELECT FROM MyTable -> SELECT FROM MYTABLE ->
> *{color:#ff}FAIL!{color}*SELECT FROM "myTable" -> SELECT FROM myTable ->
> OK
>
> Now back to Ignite case. Our schemas are case-sensitive. so the only way to
> access it is through quotes:
> CREATE SCHEMA "cacheName"; // This is what Ignite does internally
> SELECT * FROM "cacheName".myTable -> OK
> SELECT * FROM cacheName.myTable -> *{color:#ff}FAIL!{color}*
>
> Our users know this, and all their queries are written with schema names in
> quotation marks. Now consider what would happen should we change schema names
> to case-insensitive mode:
> CREATE SCHEMA cacheName;
> SELECT * FROM "cacheName".myTable -> *{color:#ff}FAIL, +all old quries
> start to fail!+{color}*
> SELECT * FROM cacheName.myTable -> OK, now it works
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7711) Explain the case-sensitivity of schema and table/cache
[
https://issues.apache.org/jira/browse/IGNITE-7711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda resolved IGNITE-7711.
-
Resolution: Won't Fix
> Explain the case-sensitivity of schema and table/cache
> --
>
> Key: IGNITE-7711
> URL: https://issues.apache.org/jira/browse/IGNITE-7711
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Magda
>Priority: Major
> Fix For: 2.7
>
>
> Users don't get how to use table and schema name in Ignite:
> [https://stackoverflow.com/questions/48723946/apache-ignite-querying-a-cache-through-an-sql-driver]
> The confusion comes from the interpretation of term "case-insensitive". All
> SQL databases work this way:
>
> 1) If I create some object and define its name without quotes, a database
> will convert it to upper case (sometimes lower case). Then if I query this
> object without quotes, a query is also transformed to upper case. This is
> what I call "case-insensitivity" - it doesn't matter how you refer to this
> object, it works still.
> CREATE TABLE myTable -> CREATE TABLE MYTABLE
> SELECT FROM myTable -> SELECT FROM MYTABLE -> OK
> SELECT FROM MyTable -> SELECT FROM MYTABLE -> OK
> SELECT FROM "myTable" -> SELECT FROM myTable -> *{color:#ff}FAIL!{color}*
>
> 2) If I create an object with quotes, then the database doesn't convert it to
> upper case, and the original name in quotes is *the only way* to access the
> object:
> CREATE TABLE "myTable" -> CREATE TABLE myTable
> SELECT FROM myTable -> SELECT FROM MYTABLE -> *{color:#ff}FAIL!{color}*
> SELECT FROM MyTable -> SELECT FROM MYTABLE ->
> *{color:#ff}FAIL!{color}*SELECT FROM "myTable" -> SELECT FROM myTable ->
> OK
>
> Now back to Ignite case. Our schemas are case-sensitive. so the only way to
> access it is through quotes:
> CREATE SCHEMA "cacheName"; // This is what Ignite does internally
> SELECT * FROM "cacheName".myTable -> OK
> SELECT * FROM cacheName.myTable -> *{color:#ff}FAIL!{color}*
>
> Our users know this, and all their queries are written with schema names in
> quotation marks. Now consider what would happen should we change schema names
> to case-insensitive mode:
> CREATE SCHEMA cacheName;
> SELECT * FROM "cacheName".myTable -> *{color:#ff}FAIL, +all old quries
> start to fail!+{color}*
> SELECT * FROM cacheName.myTable -> OK, now it works
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7739) Write about Spring Injection and IgniteSpringBean in documentation
[ https://issues.apache.org/jira/browse/IGNITE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7739: Fix Version/s: (was: 2.7) 2.8 > Write about Spring Injection and IgniteSpringBean in documentation > -- > > Key: IGNITE-7739 > URL: https://issues.apache.org/jira/browse/IGNITE-7739 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Ilya Kasnacheev >Priority: Major > Fix For: 2.8 > > > Currently there is no mention of IgniteSpringBean on readme.io > We have section https://apacheignite.readme.io/docs/resource-injection but > it's totally not obvious how to make e.g. SpringResource work, what are > pre-requisites. > Thing is, if Ignite creates Spring context (via Ignition), then Spring > injection would work out of box. > If Spring context creates Ignite as a bean, that bean should be > IgniteSpringBean and not Ignite. Otherwise, Spring context and lifecycle > would not be visible to Ignite and injection won't work. > On unrelated note, maybe we need support for Spring Boot already? See > https://habrahabr.ru/post/310672/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7781) JMX beans documentation
[ https://issues.apache.org/jira/browse/IGNITE-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7781: Fix Version/s: (was: 2.7) 2.8 > JMX beans documentation > --- > > Key: IGNITE-7781 > URL: https://issues.apache.org/jira/browse/IGNITE-7781 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Assignee: Prachi Garg >Priority: Major > Labels: documentation, jmx > Fix For: 2.8 > > Attachments: MXBeansJavaDoc.zip > > > There are about 30 JMX beans implemented in Ignite, but there is no > documentation for most of these beans, except memory metrics and brief > overview of cache metrics. > Folowing MBeans/MXBeans can be documented: > ||MBeans group||Interface||Path||Comment|| > |Eviction > metrics|org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicyMBean, > org.apache.ignite.cache.eviction.igfs.IgfsPerBlockLruEvictionPolicyMXBean, > org.apache.ignite.cache.eviction.lru.LruEvictionPolicyMBean, > org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicyMBean|org.apache|For > each cache, if eviction for cache is configured| > |Cache group > metrics|org.apache.ignite.mxbean.CacheGroupMetricsMXBean|org.apache..."Cache > groups".|For each group| > |Cache > metrics|org.apache.ignite.mxbean.CacheMetricsMXBean|org.apacheCacheClusterMetricsMXBeanImpl, > > org.apacheCacheLocalMetricsMXBeanImpl|For > each cache| > |Cluster > metrics|org.apache.ignite.mxbean.ClusterMetricsMXBean|org.apache...Kernal.ClusterLocalNodeMetricsMXBeanImpl, > org.apache...Kernal.ClusterMetricsMXBeanImpl| > |Data region (memory) > metrics|org.apache.ignite.mxbean.DataRegionMetricsMXBean|org.apache...DataRegionMetrics.|For > each data region| > |Data storage > metrics|org.apache.ignite.mxbean.DataStorageMetricsMXBean|org.apache..."Persistent > Store".DataStorageMetrics| > |Instance > information|org.apache.ignite.mxbean.IgniteMXBean|org.apache...Kernal.IgniteKernal| > |Ignition > state|org.apache.ignite.mxbean.IgnitionMXBean|org.apache..Kernel.Ignition| > |Thread pools metrics|org.apache.ignite.mxbean.ThreadPoolMXBean, > org.apache.ignite.mxbean.StripedExecutorMXBean|org.apache..."Thread > Pools".|For each executor| > |SPI|org.apache.ignite.spi.cache.CacheCheckpointSpiMBean, > org.apache.ignite.spi.collision.fifoqueue.FifoQueueCollisionSpiMBean, > org.apache.ignite.spi.collision.jobstealing.JobStealingCollisionSpiMBean, > org.apache.ignite.spi.collision.priorityqueue.PriorityQueueCollisionSpiMBean, > org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiMBean, > org.apache.ignite.spi.deployment.local.LocalDeploymentSpiMBean, > org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpiMBean, > org.apache.ignite.spi.eventstorage.memory.MemoryEventStorageSpiMBean, > org.apache.ignite.spi.failover.always.AlwaysFailoverSpiMBean, > org.apache.ignite.spi.failover.jobstealing.JobStealingFailoverSpiMBean, > org.apache.ignite.spi.failover.never.NeverFailoverSpiMBean, > org.apache.ignite.spi.jdbc.JdbcCheckpointSpiMBean, > org.apache.ignite.spi.loadbalancing.adaptive.AdaptiveLoadBalancingSpiMBean, > org.apache.ignite.spi.loadbalancing.roundrobin.RoundRobinLoadBalancingSpiMBean, > > org.apache.ignite.spi.loadbalancing.weightedrandom.WeightedRandomLoadBalancingSpiMBean, > > org.apache.ignite.spi.sharedfs.SharedFsCheckpointSpiMBean|org.apache...SPIs.| > > JavaDoc for this beans is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7781) JMX beans documentation
[ https://issues.apache.org/jira/browse/IGNITE-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7781: --- Assignee: Artem Budnikov (was: Prachi Garg) > JMX beans documentation > --- > > Key: IGNITE-7781 > URL: https://issues.apache.org/jira/browse/IGNITE-7781 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Assignee: Artem Budnikov >Priority: Major > Labels: documentation, jmx > Fix For: 2.8 > > Attachments: MXBeansJavaDoc.zip > > > There are about 30 JMX beans implemented in Ignite, but there is no > documentation for most of these beans, except memory metrics and brief > overview of cache metrics. > Folowing MBeans/MXBeans can be documented: > ||MBeans group||Interface||Path||Comment|| > |Eviction > metrics|org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicyMBean, > org.apache.ignite.cache.eviction.igfs.IgfsPerBlockLruEvictionPolicyMXBean, > org.apache.ignite.cache.eviction.lru.LruEvictionPolicyMBean, > org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicyMBean|org.apache|For > each cache, if eviction for cache is configured| > |Cache group > metrics|org.apache.ignite.mxbean.CacheGroupMetricsMXBean|org.apache..."Cache > groups".|For each group| > |Cache > metrics|org.apache.ignite.mxbean.CacheMetricsMXBean|org.apacheCacheClusterMetricsMXBeanImpl, > > org.apacheCacheLocalMetricsMXBeanImpl|For > each cache| > |Cluster > metrics|org.apache.ignite.mxbean.ClusterMetricsMXBean|org.apache...Kernal.ClusterLocalNodeMetricsMXBeanImpl, > org.apache...Kernal.ClusterMetricsMXBeanImpl| > |Data region (memory) > metrics|org.apache.ignite.mxbean.DataRegionMetricsMXBean|org.apache...DataRegionMetrics.|For > each data region| > |Data storage > metrics|org.apache.ignite.mxbean.DataStorageMetricsMXBean|org.apache..."Persistent > Store".DataStorageMetrics| > |Instance > information|org.apache.ignite.mxbean.IgniteMXBean|org.apache...Kernal.IgniteKernal| > |Ignition > state|org.apache.ignite.mxbean.IgnitionMXBean|org.apache..Kernel.Ignition| > |Thread pools metrics|org.apache.ignite.mxbean.ThreadPoolMXBean, > org.apache.ignite.mxbean.StripedExecutorMXBean|org.apache..."Thread > Pools".|For each executor| > |SPI|org.apache.ignite.spi.cache.CacheCheckpointSpiMBean, > org.apache.ignite.spi.collision.fifoqueue.FifoQueueCollisionSpiMBean, > org.apache.ignite.spi.collision.jobstealing.JobStealingCollisionSpiMBean, > org.apache.ignite.spi.collision.priorityqueue.PriorityQueueCollisionSpiMBean, > org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiMBean, > org.apache.ignite.spi.deployment.local.LocalDeploymentSpiMBean, > org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpiMBean, > org.apache.ignite.spi.eventstorage.memory.MemoryEventStorageSpiMBean, > org.apache.ignite.spi.failover.always.AlwaysFailoverSpiMBean, > org.apache.ignite.spi.failover.jobstealing.JobStealingFailoverSpiMBean, > org.apache.ignite.spi.failover.never.NeverFailoverSpiMBean, > org.apache.ignite.spi.jdbc.JdbcCheckpointSpiMBean, > org.apache.ignite.spi.loadbalancing.adaptive.AdaptiveLoadBalancingSpiMBean, > org.apache.ignite.spi.loadbalancing.roundrobin.RoundRobinLoadBalancingSpiMBean, > > org.apache.ignite.spi.loadbalancing.weightedrandom.WeightedRandomLoadBalancingSpiMBean, > > org.apache.ignite.spi.sharedfs.SharedFsCheckpointSpiMBean|org.apache...SPIs.| > > JavaDoc for this beans is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7870) Update Discovery and Communication Technical Docs
[ https://issues.apache.org/jira/browse/IGNITE-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-7870. - Resolution: Won't Fix > Update Discovery and Communication Technical Docs > - > > Key: IGNITE-7870 > URL: https://issues.apache.org/jira/browse/IGNITE-7870 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > Attachments: IgniteNetworkingOverview.md > > > Existing discovery and communication pages are not in the best shape and > require an overhaul. Use the revisited version (attached) contributed by a > community member and see how to improve or mix discovery, communication, > servers & clients docs from readme. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7870) Update Discovery and Communication Technical Docs
[ https://issues.apache.org/jira/browse/IGNITE-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-7870. --- > Update Discovery and Communication Technical Docs > - > > Key: IGNITE-7870 > URL: https://issues.apache.org/jira/browse/IGNITE-7870 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > Attachments: IgniteNetworkingOverview.md > > > Existing discovery and communication pages are not in the best shape and > require an overhaul. Use the revisited version (attached) contributed by a > community member and see how to improve or mix discovery, communication, > servers & clients docs from readme. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7903) Explain how to tune performance by using WAL modes
[ https://issues.apache.org/jira/browse/IGNITE-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7903: --- Assignee: Artem Budnikov (was: Prachi Garg) > Explain how to tune performance by using WAL modes > -- > > Key: IGNITE-7903 > URL: https://issues.apache.org/jira/browse/IGNITE-7903 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > Explain how to improve performance by switching between the WAL modes: > https://apacheignite.readme.io/docs/durable-memory-tuning > Basically, LOG_ONLY and BACKGROUND mode can be considered as an alternative > for FULL_SYNC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6983) SQL: Optimize CREATE INDEX and BPlusTree interaction
[
https://issues.apache.org/jira/browse/IGNITE-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov resolved IGNITE-6983.
--
Resolution: Won't Fix
The performance impact is not significant.
> SQL: Optimize CREATE INDEX and BPlusTree interaction
>
>
> Key: IGNITE-6983
> URL: https://issues.apache.org/jira/browse/IGNITE-6983
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-19, performance
>
> Currently index is built as follows:
> 1) Get next entry from partition's tree
> 2) Read it's key (copy to heap)
> 3) Acquire lock on {{GridCacheMapEntry}}
> 4) Lookup the same key in the tree from the top
> 5) Read it's value (copy to heap)
> 6) Add to index.
> This is very complex flow. We can optimize two things - tree lookup and value
> deserialization as follows:
> 1) Every data page will have update counter, which is incremented every time
> anything is changed.
> 2) When lock on {{GridCacheMapEntry}} is acquired, we will acquire lock on
> the data page and re-check update counter.
> 3) If page was changed between iterator read and lock acquisition then use
> old flow.
> 4) Otherwise - set read lock on the page, read value as *offheap* object,
> apply it to index.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7906) Create languages comparison page
[ https://issues.apache.org/jira/browse/IGNITE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7906: Fix Version/s: (was: 2.7) 2.8 > Create languages comparison page > - > > Key: IGNITE-7906 > URL: https://issues.apache.org/jira/browse/IGNITE-7906 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > > In addition to Java, .NET and C++ thick clients, the community is going to > support a variety of thin client for many other languages such as Python, > Node.JS, etc. It will be beneficial to create a page that depicts > capabilities of every language like this one: > https://hazelcast.org/clients-languages/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8091) Create Ignite monitoring guide describing metrics and monitoring facilities
[ https://issues.apache.org/jira/browse/IGNITE-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-8091: Fix Version/s: (was: 2.7) 2.8 > Create Ignite monitoring guide describing metrics and monitoring facilities > --- > > Key: IGNITE-8091 > URL: https://issues.apache.org/jira/browse/IGNITE-8091 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Priority: Major > Labels: iep-6 > Fix For: 2.8 > > > Ignite doesn't have a single documentation section which would aggregate all > the metrics the project has. There are random documentation pages spread out > across data grid, memory, persistence and other topics. > The new section will include the following: > * How to gather metrics (JMX, logs, APIs) > * Detailed metrics coverage for memory, persistence, rebalancing, compute, > etc. Consider IGNITE-8078 and IGNITE-8077 > * Monitoring tools > * How to integrate with 3rd party tools. > Use a draft of a monitoring guide as a reference: > https://docs.google.com/document/d/1yl7XoiWWPg_XGhwZJUg9Mm3muEApefoMiNLxEUxggV4/edit# -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607246#comment-16607246 ] Denis Magda commented on IGNITE-8212: - [~pgarg], please work with Igor to get this done for 2.7 > Binary Client Protocol spec: Key-Value Queries clarifications > - > > Key: IGNITE-8212 > URL: https://issues.apache.org/jira/browse/IGNITE-8212 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations > - all operations - "Flag. Pass 0 for default, or 1 to keep the value in > binary form": > -- remove words about binary form and keep "Pass 0 for default" for all > operations where this flag has no meaning. > -- clarify about binary form in operations where it has a meaning. > - OP_CACHE_GET: clarify that null is returned if the provided key does not > exist in the cache. > - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided > key does not exist in the cache, and null is returned in this case. > - OP_CACHE_GET_AND_REPLACE: > -- "if and only if there is a value currently mapped for that key" - is > confusing. Is it possible that an existing key has no associated value? > Suggest to rephrase as "if and only if the key exists in the cache" > -- clarify that null is returned if the key does not exist in the cache. > - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not > exist in the cache. > - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new > entry is created, false if the specified key already exists in the cache. > - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of > whether put happened or not" - is confusing. Suggest to rewrite "the current > value associated with the key if it already exists in the cache, null if the > new entry is created". > - OP_CACHE_GET_SIZE: clarify Peek modes > - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX: > -- what is the difference between the corresponding operations? Only in > notifying / not notifying listeners and cache writers? Or there are other > differences not clarified by the spec? > -- (the operations could be combined in one set - with a flag required/not > required notifications) > -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no > OP_CACHE_CLEAR_IF_EQUALS. Is it intentional? > -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating > whether remove happened" in the response. But OP_CACHE_CLEAR_KEY does not > have such a flag in the response. Is it intentional? > -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of > the specified keys do not exist other entries are removed anyway. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8137) Explain how to see SQL schema and table structure in Ignite
[
https://issues.apache.org/jira/browse/IGNITE-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-8137:
Fix Version/s: (was: 2.7)
2.8
> Explain how to see SQL schema and table structure in Ignite
> ---
>
> Key: IGNITE-8137
> URL: https://issues.apache.org/jira/browse/IGNITE-8137
> Project: Ignite
> Issue Type: New Feature
> Components: documentation
>Reporter: Denis Magda
>Priority: Major
> Fix For: 2.8
>
>
> Presently, Ignite doesn't ship {{SHOW TABLE}} command. Thus, it's not clear
> how to get tables and schema structures in Ignite.
> Until this command is not supported we have to explain that:
> * Many tools use JDBC and ODBC metadata related parameters can pull that
> information out of there and present it to an end user. For instance, SQLline
> utilizes {{!table}} command that gets data from JDBC metadata methods.
> DBeaver utilizes the same approach.
> * Let's create {{Database Administration}} section under SQL reference
> (https://apacheignite-sql.readme.io/docs/sql-reference-overview) and
> presently list approaches supported by various tools (sqlline, dbeaver, etc)
> and how to get the same information from the drivers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7846) SQL: support COPY command by native SQL
[ https://issues.apache.org/jira/browse/IGNITE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-7846: - Fix Version/s: (was: 2.7) > SQL: support COPY command by native SQL > --- > > Key: IGNITE-7846 > URL: https://issues.apache.org/jira/browse/IGNITE-7846 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.3 >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > > The COPY command is supported only for JDBC client (IGNITE-6917). > It must be supported by native SQL API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16607245#comment-16607245 ] Denis Magda commented on IGNITE-8411: - [~pgarg], please work with Igor to get this done for 2.7 > 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.7 > > > 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 (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8212: --- Assignee: Igor Sapego (was: Vladimir Ozerov) > Binary Client Protocol spec: Key-Value Queries clarifications > - > > Key: IGNITE-8212 > URL: https://issues.apache.org/jira/browse/IGNITE-8212 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations > - all operations - "Flag. Pass 0 for default, or 1 to keep the value in > binary form": > -- remove words about binary form and keep "Pass 0 for default" for all > operations where this flag has no meaning. > -- clarify about binary form in operations where it has a meaning. > - OP_CACHE_GET: clarify that null is returned if the provided key does not > exist in the cache. > - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided > key does not exist in the cache, and null is returned in this case. > - OP_CACHE_GET_AND_REPLACE: > -- "if and only if there is a value currently mapped for that key" - is > confusing. Is it possible that an existing key has no associated value? > Suggest to rephrase as "if and only if the key exists in the cache" > -- clarify that null is returned if the key does not exist in the cache. > - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not > exist in the cache. > - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new > entry is created, false if the specified key already exists in the cache. > - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of > whether put happened or not" - is confusing. Suggest to rewrite "the current > value associated with the key if it already exists in the cache, null if the > new entry is created". > - OP_CACHE_GET_SIZE: clarify Peek modes > - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX: > -- what is the difference between the corresponding operations? Only in > notifying / not notifying listeners and cache writers? Or there are other > differences not clarified by the spec? > -- (the operations could be combined in one set - with a flag required/not > required notifications) > -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no > OP_CACHE_CLEAR_IF_EQUALS. Is it intentional? > -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating > whether remove happened" in the response. But OP_CACHE_CLEAR_KEY does not > have such a flag in the response. Is it intentional? > -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of > the specified keys do not exist other entries are removed anyway. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8629) There is no documentation about on which nodes Ignite Predicate will be executed during service/cache deploying with NodeFilter
[
https://issues.apache.org/jira/browse/IGNITE-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-8629:
Fix Version/s: (was: 2.7)
2.8
> There is no documentation about on which nodes Ignite Predicate will be
> executed during service/cache deploying with NodeFilter
> ---
>
> Key: IGNITE-8629
> URL: https://issues.apache.org/jira/browse/IGNITE-8629
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
>
> In documentation we could see that:
> [https://apacheignite.readme.io/docs/service-grid#section-node-filter-based-deployment]
> This approach is based on a filtering predicate that gets called on every
> node at the time Ignite Service engine determines a set of possible
> candidates for the Ignite Service deployment.
> Looks like it's not correct because in Ignite 2.4 next code:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite2.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> @IgniteInstanceResource Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Will be executed only on "ignite-1"
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> Looks like ignite-1 is the coordinator node in this case. But this behavior
> is different from described in the documentation.
> Also, this should be described in case of the cache deployment:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite2.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-8671) Provide instructions on running Apache Ignite on Windows 10 WSL Environment
[ https://issues.apache.org/jira/browse/IGNITE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8671. --- > Provide instructions on running Apache Ignite on Windows 10 WSL Environment > --- > > Key: IGNITE-8671 > URL: https://issues.apache.org/jira/browse/IGNITE-8671 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.7 > > > Prepare instructions (and possibly update official documentation) on running > Apache Ignite as systemd service on Windows 10 WSL Ubuntu using official DEB > package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8654) Move SET command documentation to Operational Commands section
[ https://issues.apache.org/jira/browse/IGNITE-8654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8654. --- > Move SET command documentation to Operational Commands section > -- > > Key: IGNITE-8654 > URL: https://issues.apache.org/jira/browse/IGNITE-8654 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > We need to be consistent and document SQL commands under SQL Reference > section. > So, move and slightly rework (no need to show step by step JDBC example) the > doc from here: > [https://apacheignite-sql.readme.io/v2.5/docs/jdbc-driver#section-streaming] > there: > [https://apacheignite-sql.readme.io/v2.5/docs/set] > Once moved, ensure the format complies with the rest of the commands and > there is a callout saying the feature is supported for JDBC only. Refer to > COPY as to an example: > [https://apacheignite-sql.readme.io/v2.5/docs/copy] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8671) Provide instructions on running Apache Ignite on Windows 10 WSL Environment
[ https://issues.apache.org/jira/browse/IGNITE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-8671. - Resolution: Fixed > Provide instructions on running Apache Ignite on Windows 10 WSL Environment > --- > > Key: IGNITE-8671 > URL: https://issues.apache.org/jira/browse/IGNITE-8671 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.7 > > > Prepare instructions (and possibly update official documentation) on running > Apache Ignite as systemd service on Windows 10 WSL Ubuntu using official DEB > package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9345) Document custom SQL schemas
[
https://issues.apache.org/jira/browse/IGNITE-9345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-9345:
---
Assignee: Artem Budnikov
> Document custom SQL schemas
> ---
>
> Key: IGNITE-9345
> URL: https://issues.apache.org/jira/browse/IGNITE-9345
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Critical
> Fix For: 2.7
>
>
> Key highlights:
> 1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
> \{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
> from docs (if there is such paragraph)
> 2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
> schemas with provided names.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9345) Document custom SQL schemas
[
https://issues.apache.org/jira/browse/IGNITE-9345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-9345:
Priority: Critical (was: Major)
> Document custom SQL schemas
> ---
>
> Key: IGNITE-9345
> URL: https://issues.apache.org/jira/browse/IGNITE-9345
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 2.7
>
>
> Key highlights:
> 1) DDL operations \{{CREATE TABLE}} and \{{DROP TABLE}} are no longer tied to
> \{{PUBLIC}} schema. They can be executed on any schema. Need to remove this
> from docs (if there is such paragraph)
> 2) Added a property \{{IgniteConfiguration.sqlSchemas}} which creates local
> schemas with provided names.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9406) Improve SQL "Performance and Debugging" page
[ https://issues.apache.org/jira/browse/IGNITE-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-9406: Fix Version/s: (was: 2.7) 2.8 > Improve SQL "Performance and Debugging" page > > > Key: IGNITE-9406 > URL: https://issues.apache.org/jira/browse/IGNITE-9406 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Attachments: ignite_sql_perf.txt > > > I prepared a document for one of Ignite clients with some advanced > information about how various performance optimizations work in Ignite SQL. > Let's compare this document with our "Performance and Debugging" page [1], > and enhance the latter with missing info (if any). > P.S.: Document is attached. Russian language. > [1] > https://apacheignite-sql.readme.io/docs/performance-and-debugging#query-execution-flow-optimizations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9475) Closures that has been created on client does not provide real class name to TASK_* permissions
[
https://issues.apache.org/jira/browse/IGNITE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607229#comment-16607229
]
Dmitriy Govorukhin commented on IGNITE-9475:
[~ibessonov] Changes merged to master.
> Closures that has been created on client does not provide real class name to
> TASK_* permissions
> ---
>
> Key: IGNITE-9475
> URL: https://issues.apache.org/jira/browse/IGNITE-9475
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.7
>
>
> Broadcast job for example get
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6 task
> name.
> This combination of java + xml config
> {code:java}
> ignite.compute(ignite.cluster().forServers()).broadcast(new
> DistributedJob(cacheName));
> {code}
> {code:java}
>{
>
> task:'org.apache.ignite.piclient.operations.DistributedChecksumOperation$DistributedJob',
>
> permissions:[TASK_EXECUTE]
>},
> {code}
> provides following error
> {code:java}
> Authorization failed [perm=TASK_EXECUTE,
> name=org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6,
> ... ]
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9475) Closures that has been created on client does not provide real class name to TASK_* permissions
[
https://issues.apache.org/jira/browse/IGNITE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607223#comment-16607223
]
ASF GitHub Bot commented on IGNITE-9475:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4688
> Closures that has been created on client does not provide real class name to
> TASK_* permissions
> ---
>
> Key: IGNITE-9475
> URL: https://issues.apache.org/jira/browse/IGNITE-9475
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.7
>
>
> Broadcast job for example get
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6 task
> name.
> This combination of java + xml config
> {code:java}
> ignite.compute(ignite.cluster().forServers()).broadcast(new
> DistributedJob(cacheName));
> {code}
> {code:java}
>{
>
> task:'org.apache.ignite.piclient.operations.DistributedChecksumOperation$DistributedJob',
>
> permissions:[TASK_EXECUTE]
>},
> {code}
> provides following error
> {code:java}
> Authorization failed [perm=TASK_EXECUTE,
> name=org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6,
> ... ]
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9288) Document how to start Ignite under Java 9
[
https://issues.apache.org/jira/browse/IGNITE-9288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9288:
Description:
*Explanation of the problem*
AI use some proprietary DK APIs which are not accessible by default. In order
to run Ignite, it is necessary to pass special JVM flags to make these APIs
accessible.
*How to start embedded Ignite*
Pass the following flags to JVM:
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports
java.base/sun.nio.ch=ALL-UNNAMED --add-exports
java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports
jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
*How to start standalone Ignite node*
No additional actions are needed. Flag are already passed to Java inside
{{ignite.sh/bat}}
> Document how to start Ignite under Java 9
> -
>
> Key: IGNITE-9288
> URL: https://issues.apache.org/jira/browse/IGNITE-9288
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> *Explanation of the problem*
> AI use some proprietary DK APIs which are not accessible by default. In order
> to run Ignite, it is necessary to pass special JVM flags to make these APIs
> accessible.
> *How to start embedded Ignite*
> Pass the following flags to JVM:
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports
> java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED --add-exports
> jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED
> *How to start standalone Ignite node*
> No additional actions are needed. Flag are already passed to Java inside
> {{ignite.sh/bat}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9475) Closures that has been created on client does not provide real class name to TASK_* permissions
[
https://issues.apache.org/jira/browse/IGNITE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607210#comment-16607210
]
Ilya Lantukh commented on IGNITE-9475:
--
Thanks for contribution, changes look good to me.
> Closures that has been created on client does not provide real class name to
> TASK_* permissions
> ---
>
> Key: IGNITE-9475
> URL: https://issues.apache.org/jira/browse/IGNITE-9475
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.7
>
>
> Broadcast job for example get
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6 task
> name.
> This combination of java + xml config
> {code:java}
> ignite.compute(ignite.cluster().forServers()).broadcast(new
> DistributedJob(cacheName));
> {code}
> {code:java}
>{
>
> task:'org.apache.ignite.piclient.operations.DistributedChecksumOperation$DistributedJob',
>
> permissions:[TASK_EXECUTE]
>},
> {code}
> provides following error
> {code:java}
> Authorization failed [perm=TASK_EXECUTE,
> name=org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6,
> ... ]
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9472) REST API has no permission checks for cluster activation/deactivation
[ https://issues.apache.org/jira/browse/IGNITE-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607209#comment-16607209 ] ASF GitHub Bot commented on IGNITE-9472: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4686 > REST API has no permission checks for cluster activation/deactivation > - > > Key: IGNITE-9472 > URL: https://issues.apache.org/jira/browse/IGNITE-9472 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > ADMIN_OPS permission should be required for CLUSTER_ACTIVE / CLUSTER_INACTIVE > commands. This has to be done in GridRestProcessor.authorize method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9475) Closures that has been created on client does not provide real class name to TASK_* permissions
[
https://issues.apache.org/jira/browse/IGNITE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-9475:
---
Fix Version/s: 2.7
> Closures that has been created on client does not provide real class name to
> TASK_* permissions
> ---
>
> Key: IGNITE-9475
> URL: https://issues.apache.org/jira/browse/IGNITE-9475
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.7
>
>
> Broadcast job for example get
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6 task
> name.
> This combination of java + xml config
> {code:java}
> ignite.compute(ignite.cluster().forServers()).broadcast(new
> DistributedJob(cacheName));
> {code}
> {code:java}
>{
>
> task:'org.apache.ignite.piclient.operations.DistributedChecksumOperation$DistributedJob',
>
> permissions:[TASK_EXECUTE]
>},
> {code}
> provides following error
> {code:java}
> Authorization failed [perm=TASK_EXECUTE,
> name=org.apache.ignite.internal.processors.closure.GridClosureProcessor$T6,
> ... ]
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9472) REST API has no permission checks for cluster activation/deactivation
[ https://issues.apache.org/jira/browse/IGNITE-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607207#comment-16607207 ] Dmitriy Govorukhin commented on IGNITE-9472: [~ibessonov] Thanks for the contribution, merged to master. > REST API has no permission checks for cluster activation/deactivation > - > > Key: IGNITE-9472 > URL: https://issues.apache.org/jira/browse/IGNITE-9472 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > ADMIN_OPS permission should be required for CLUSTER_ACTIVE / CLUSTER_INACTIVE > commands. This has to be done in GridRestProcessor.authorize method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4750) SQL: Support GROUP_CONCAT function
[ https://issues.apache.org/jira/browse/IGNITE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607205#comment-16607205 ] Taras Ledkov commented on IGNITE-4750: -- [~vozerov], the test configuration is fixed. TC run is OK. > SQL: Support GROUP_CONCAT function > -- > > Key: IGNITE-4750 > URL: https://issues.apache.org/jira/browse/IGNITE-4750 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Denis Magda >Assignee: Taras Ledkov >Priority: Major > Labels: sql-engine > Fix For: 2.7 > > > GROUP_CONCAT function is not supported at the moment. Makes sense to fill > this gap: > http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html > Presently the function doc is hidden: > https://apacheignite-sql.readme.io/docs/group_concat > Open it up once the ticket is released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.
[
https://issues.apache.org/jira/browse/IGNITE-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607195#comment-16607195
]
Taras Ledkov commented on IGNITE-4150:
--
[~vozerov], tests have been re-run OK.
> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: performance
> Fix For: 2.7
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However,
> this approach doesn't work well when there are multiple {{IN}}'s.
> Proper solution would be to hack deeper into H2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9499) Node IDs are not guaranteed to be unique after reboot
Chaouki Dhib created IGNITE-9499: Summary: Node IDs are not guaranteed to be unique after reboot Key: IGNITE-9499 URL: https://issues.apache.org/jira/browse/IGNITE-9499 Project: Ignite Issue Type: Bug Reporter: Chaouki Dhib Ignite uses the JDK's UUID.randomUUID() method to generated a UUID as the the node id. This method generates UUID of variant 2 and of version 4. The version 4 is just a randomly generated ID. Therefore, there is no guarantee that after a reboot, a node will have not the same ID as before. The probably of this happening is extremely small [1], but the fact is, the current implementation is non-deterministic. The problem can easily be fixed by using a UUID of version 1 (that makes use of a timestamp and of the node's MAC address) [2]. [1] Cf [https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions] [2] [https://github.com/cowtowncoder/java-uuid-generator] provides such fonctioanlity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9498) SchemaExchangeSelfTest should use test IP finder for all discovery SPIs
[ https://issues.apache.org/jira/browse/IGNITE-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9498: - Fix Version/s: 2.7 > SchemaExchangeSelfTest should use test IP finder for all discovery SPIs > --- > > Key: IGNITE-9498 > URL: https://issues.apache.org/jira/browse/IGNITE-9498 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Currently clients use test discovery SPIs without the IP finder declared in > the test which sometimes lead to intermittent failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9498) SchemaExchangeSelfTest should use test IP finder for all discovery SPIs
[ https://issues.apache.org/jira/browse/IGNITE-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9498: - Ignite Flags: (was: Docs Required) > SchemaExchangeSelfTest should use test IP finder for all discovery SPIs > --- > > Key: IGNITE-9498 > URL: https://issues.apache.org/jira/browse/IGNITE-9498 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > Currently clients use test discovery SPIs without the IP finder declared in > the test which sometimes lead to intermittent failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9498) SchemaExchangeSelfTest should use test IP finder for all discovery SPIs
[ https://issues.apache.org/jira/browse/IGNITE-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9498: - Labels: MakeTeamcityGreenAgain (was: ) > SchemaExchangeSelfTest should use test IP finder for all discovery SPIs > --- > > Key: IGNITE-9498 > URL: https://issues.apache.org/jira/browse/IGNITE-9498 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > Currently clients use test discovery SPIs without the IP finder declared in > the test which sometimes lead to intermittent failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9498) SchemaExchangeSelfTest should use test IP finder for all discovery SPIs
[ https://issues.apache.org/jira/browse/IGNITE-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-9498: Assignee: Alexey Goncharuk PR is 4694 > SchemaExchangeSelfTest should use test IP finder for all discovery SPIs > --- > > Key: IGNITE-9498 > URL: https://issues.apache.org/jira/browse/IGNITE-9498 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > > Currently clients use test discovery SPIs without the IP finder declared in > the test which sometimes lead to intermittent failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9498) SchemaExchangeSelfTest should use test IP finder for all discovery SPIs
[ https://issues.apache.org/jira/browse/IGNITE-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9498: - Description: Currently clients use test discovery SPIs without the IP finder declared in the test which sometimes lead to intermittent failures. > SchemaExchangeSelfTest should use test IP finder for all discovery SPIs > --- > > Key: IGNITE-9498 > URL: https://issues.apache.org/jira/browse/IGNITE-9498 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > > Currently clients use test discovery SPIs without the IP finder declared in > the test which sometimes lead to intermittent failures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9498) SchemaExchangeSelfTest should use test IP finder for all discovery SPIs
Alexey Goncharuk created IGNITE-9498: Summary: SchemaExchangeSelfTest should use test IP finder for all discovery SPIs Key: IGNITE-9498 URL: https://issues.apache.org/jira/browse/IGNITE-9498 Project: Ignite Issue Type: Test Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9497) [ML] Add Pipeline support to Cross-Validation process
Aleksey Zinoviev created IGNITE-9497: Summary: [ML] Add Pipeline support to Cross-Validation process Key: IGNITE-9497 URL: https://issues.apache.org/jira/browse/IGNITE-9497 Project: Ignite Issue Type: New Feature Components: ml Affects Versions: 2.8 Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.8 Change API of ParamGrid.addHyperParam to support meta-information about Pipeline Stage Add to Cross-Validation method to support evaluate the whole Pipeline Process and inject hyper-parameters from the ParamGrid -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7782) Thin Client lib: Python
[ https://issues.apache.org/jira/browse/IGNITE-7782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Melnichuk updated IGNITE-7782: - Description: Implement Thin (lightweight) Client lib in Python programming language for Ignite Binary Client Protocol [https://apacheignite.readme.io/docs/binary-client-protocol] Prototype: [https://github.com/skozlov-gridgain/apache-ignite-python-thin-client] Example - NodeJS client - IGNITE- [https://github.com/nobitlost/ignite/tree/master/modules/platforms/nodejs] --- h5. Package name (for use with setuptools/PyPI): pyignite h5. Location of the lib in the repository: .../modules/platforms/python h5. Python version: 3.4+ (tested on 3.4 and 3.6) h5. Ignite version: 2.7. h5. Architecture: Syncronous (safe for use with threading/multiprocessing), object-oriented. h5. Documentation: Sphinx/autodoc + readme.md h5. Test framework: pytest, pytest-runner for setuptools pytest integration. h5. Usage examples included: - cache management (creating, configuring, deleting), - key-value operations, - cache scan, - basic SQL queries, - simple and advanced work with Complex objects, - fail-over connection. h5. Goal: Create a full-featured Ignite thin client library: - carefully implement, test, and document all the features of the binary protocol, that can be useful in Python programs, - implement and document features like type IDs or serialization hints, that are mostly useless in Python, for interoperability's sake, - skip features, that are not applicable to Python programs, like filter object in scan query. h5. Proposed scope of features: - basic and SSL-wrapped TCP connection, - authentication and authorization, - failover mechanism, - all datatypes, - all client operations (except Binary-Type operations with type names). was: Implement Thin (lightweight) Client lib in Python programming language for Ignite Binary Client Protocol [https://apacheignite.readme.io/v2.4/docs/binary-client-protocol] Prototype: [https://github.com/skozlov-gridgain/apache-ignite-python-thin-client] Example - NodeJS client - IGNITE- [https://github.com/nobitlost/ignite/tree/master/modules/platforms/nodejs] --- h5. Package name (for use with setuptools/PyPI): pyignite h5. Location of the lib in the repository: .../modules/platforms/python h5. Python version: 3.4+ (tested on 3.4 and 3.6) h5. Ignite version: 2.7. h5. Architecture: Syncronous (safe for use with threading/multiprocessing), object-oriented. h5. Documentation: Sphinx/autodoc + readme.md h5. Test framework: pytest, pytest-runner for setuptools pytest integration. h5. Usage examples included: - cache management (creating, configuring, deleting), - key-value operations, - cache scan, - basic SQL queries, - simple and advanced work with Complex objects, - fail-over connection. h5. Goal: Create a full-featured Ignite thin client library: - carefully implement, test, and document all the features of the binary protocol, that can be useful in Python programs, - implement and document features like type IDs or serialization hints, that are mostly useless in Python, for interoperability's sake, - skip features, that are not applicable to Python programs, like filter object in scan query. h5. Proposed scope of features: - basic and SSL-wrapped TCP connection, - authentication and authorization, - failover mechanism, - all datatypes, - all client operations (except Binary-Type operations with type names). > Thin Client lib: Python > --- > > Key: IGNITE-7782 > URL: https://issues.apache.org/jira/browse/IGNITE-7782 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.7 >Reporter: Alexey Kosenchuk >Assignee: Dmitry Melnichuk >Priority: Major > Labels: pull-request-available > Fix For: 2.7 > > > Implement Thin (lightweight) Client lib in Python programming language for > Ignite Binary Client Protocol > [https://apacheignite.readme.io/docs/binary-client-protocol] > Prototype: > [https://github.com/skozlov-gridgain/apache-ignite-python-thin-client] > Example - NodeJS client - IGNITE- > [https://github.com/nobitlost/ignite/tree/master/modules/platforms/nodejs] > --- > h5. Package name (for use with setuptools/PyPI): > pyignite > h5. Location of the lib in the repository: > .../modules/platforms/python > h5. Python version: > 3.4+ (tested on 3.4 and 3.6) > h5. Ignite version: > 2.7. > h5. Architecture: > Syncronous (safe for use with threading/multiprocessing), object-oriented. > h5. Documentation: > Sphinx/autodoc + readme.md > h5. Test framework: > pytest, pytest-runner for setuptools pytest integration. > h5. Usage examples
[jira] [Created] (IGNITE-9496) Add listenAsync method to GridFutureAdapter
Pavel Kovalenko created IGNITE-9496: --- Summary: Add listenAsync method to GridFutureAdapter Key: IGNITE-9496 URL: https://issues.apache.org/jira/browse/IGNITE-9496 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Fix For: 2.7 Currently, there is no possibility to add an async listener to an internal future with the possibility to choose an appropriate executor for such listener. This would be useful to change thread that will execute a future listener. We should add listenAsync method to GridFutureAdapter and add the possibility to set arbitrary submitter/executor for such listeners. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9495) Update version for org.apache.lucene lucene-queryparser : 5.5.2
[ https://issues.apache.org/jira/browse/IGNITE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov reassigned IGNITE-9495: --- Assignee: Maxim Pudov > Update version for org.apache.lucene lucene-queryparser : 5.5.2 > --- > > Key: IGNITE-9495 > URL: https://issues.apache.org/jira/browse/IGNITE-9495 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Alexander Gerus >Assignee: Maxim Pudov >Priority: Major > > Update version for org.apache.lucene > Current version: lucene-queryparser : 5.5.2 > New version version: later than 7.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9495) Update version for org.apache.lucene lucene-queryparser : 5.5.2
Alexander Gerus created IGNITE-9495: --- Summary: Update version for org.apache.lucene lucene-queryparser : 5.5.2 Key: IGNITE-9495 URL: https://issues.apache.org/jira/browse/IGNITE-9495 Project: Ignite Issue Type: Improvement Affects Versions: 2.6, 2.5, 2.4 Reporter: Alexander Gerus Update version for org.apache.lucene Current version: lucene-queryparser : 5.5.2 New version version: later than 7.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8879) Blinking baseline node sometimes unable to connect to cluster
[
https://issues.apache.org/jira/browse/IGNITE-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-8879:
-
Assignee: Vladislav Pyatkov
> Blinking baseline node sometimes unable to connect to cluster
> -
>
> Key: IGNITE-8879
> URL: https://issues.apache.org/jira/browse/IGNITE-8879
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Attachments: IGNITE-8879.zip
>
>
> Almost the same scenario as in IGNITE-8874 but node left baseline while
> blinking
> All caches with 2 backups
> 4 nodes in cluster
> # Start cluster, load data
> # Start transactional loading (8 threads, 100 ops/second put/get in each op)
> # Repeat 10 times: kill one node, remove from baseline, start node again
> (*with no LFS clean*), wait for rebalance
> # Check idle_verify, check data corruption
>
> At some point killed node unable to start and join cluster because of error
> (Attachments info: grid.1.node2.X.log - blinking node logs, X - iteration
> counter from step 3)
> {code:java}
> 080ee8-END.bin]
> [2018-06-26 19:01:43,039][INFO ][main][PageMemoryImpl] Started page memory
> [memoryAllocated=100.0 MiB, pages=24800, tableSize=1.9 MiB,
> checkpointBuffer=100.0 MiB]
> [2018-06-26 19:01:43,039][INFO ][main][GridCacheDatabaseSharedManager]
> Checking memory state [lastValidPos=FileWALPointer [idx=0, fileOff=583691,
> len=119], lastMarked=FileWALPointer [idx=0, fileOff=583691, len=119],
> lastCheckpointId=7fca4dbb-8f01-4b63-95e2-43283b080ee8]
> [2018-06-26 19:01:43,050][INFO ][main][GridCacheDatabaseSharedManager] Found
> last checkpoint marker [cpId=7fca4dbb-8f01-4b63-95e2-43283b080ee8,
> pos=FileWALPointer [idx=0, fileOff=583691, len=119]]
> [2018-06-26 19:01:43,082][INFO ][main][FileWriteAheadLogManager] Stopping WAL
> iteration due to an exception: EOF at position [100] expected to read [1]
> bytes, ptr=FileWALPointer [idx=0, fileOff=100, len=0]
> [2018-06-26 19:01:43,219][WARN ][main][FileWriteAheadLogManager] WAL segment
> tail is reached. [ Expected next state: {Index=19,Offset=794017}, Actual
> state : {Index=3602879702215753728,Offset=775434544} ]
> [2018-06-26 19:01:43,243][INFO ][main][GridCacheDatabaseSharedManager]
> Applying lost cache updates since last checkpoint record
> [lastMarked=FileWALPointer [idx=0, fileOff=583691, len=119],
> lastCheckpointId=7fca4dbb-8f01-4b63-95e2-43283b080ee8]
> [2018-06-26 19:01:43,246][INFO ][main][FileWriteAheadLogManager] Stopping WAL
> iteration due to an exception: EOF at position [100] expected to read [1]
> bytes, ptr=FileWALPointer [idx=0, fileOff=100, len=0]
> [2018-06-26 19:01:43,336][WARN ][main][FileWriteAheadLogManager] WAL segment
> tail is reached. [ Expected next state: {Index=19,Offset=794017}, Actual
> state : {Index=3602879702215753728,Offset=775434544} ]
> [2018-06-26 19:01:43,336][INFO ][main][GridCacheDatabaseSharedManager]
> Finished applying WAL changes [updatesApplied=0, time=101ms]
> [2018-06-26 19:01:43,450][INFO
> ][main][GridSnapshotAwareClusterStateProcessorImpl] Restoring history for
> BaselineTopology[id=4]
> [2018-06-26 19:01:43,454][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections
> class org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1769)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1001)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
> at org.apache.ignite.Ignition.start(Ignition.java:352)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
> Caused by: class org.apache.ignite.IgniteCheckedException: Restoring of
> BaselineTopology history has failed, expected history item not found for id=1
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
> at
>
[jira] [Commented] (IGNITE-8149) MVCC TX: Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607103#comment-16607103 ] ASF GitHub Bot commented on IGNITE-8149: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4654 > MVCC TX: Size method should use tx snapshot > --- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.7 > > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9493) Communication error resolver shouldn't be invoked if connection with client breaks unexpectedly
[ https://issues.apache.org/jira/browse/IGNITE-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-9493: Component/s: zookeeper > Communication error resolver shouldn't be invoked if connection with client > breaks unexpectedly > --- > > Key: IGNITE-9493 > URL: https://issues.apache.org/jira/browse/IGNITE-9493 > Project: Ignite > Issue Type: Bug > Components: cache, zookeeper >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Currently, we initiate communication error resolving process even if a > connection between server and client breaks unexpectedly. > This is unnecessary action because client nodes are not important for cluster > stability. We should ignore communication errors for client and daemon nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9399) Document new WAL history size configuration parameter
[ https://issues.apache.org/jira/browse/IGNITE-9399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-9399: -- Assignee: Artem Budnikov > Document new WAL history size configuration parameter > - > > Key: IGNITE-9399 > URL: https://issues.apache.org/jira/browse/IGNITE-9399 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Artem Budnikov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9494) Communication error resolver may be invoked when topology is under construction
[ https://issues.apache.org/jira/browse/IGNITE-9494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-9494: Component/s: zookeeper > Communication error resolver may be invoked when topology is under > construction > --- > > Key: IGNITE-9494 > URL: https://issues.apache.org/jira/browse/IGNITE-9494 > Project: Ignite > Issue Type: Bug > Components: cache, zookeeper >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Zookeeper Discovery. > During massive node start and join to topology there can happen communication > error problems which can lead to invoking communication error resolver. > Communication error resolver initiates a peer-to-peer ping process on all > alive nodes. Youngest nodes in a cluster may have the not complete picture > about alive nodes in a cluster. This can lead to a situation, that youngest > node will not ping all available nodes, and the coordinator may decide that > those nodes have an unstable network and unexpectedly kill them. > We should throttle communication error resolver in case of massive node join > and give them a time to get the complete picture about topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9494) Communication error resolver may be invoked when topology is under construction
Pavel Kovalenko created IGNITE-9494: --- Summary: Communication error resolver may be invoked when topology is under construction Key: IGNITE-9494 URL: https://issues.apache.org/jira/browse/IGNITE-9494 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Fix For: 2.7 Zookeeper Discovery. During massive node start and join to topology there can happen communication error problems which can lead to invoking communication error resolver. Communication error resolver initiates a peer-to-peer ping process on all alive nodes. Youngest nodes in a cluster may have the not complete picture about alive nodes in a cluster. This can lead to a situation, that youngest node will not ping all available nodes, and the coordinator may decide that those nodes have an unstable network and unexpectedly kill them. We should throttle communication error resolver in case of massive node join and give them a time to get the complete picture about topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9493) Communication error resolver shouldn't be invoked if connection with client breaks unexpectedly
Pavel Kovalenko created IGNITE-9493: --- Summary: Communication error resolver shouldn't be invoked if connection with client breaks unexpectedly Key: IGNITE-9493 URL: https://issues.apache.org/jira/browse/IGNITE-9493 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Fix For: 2.7 Currently, we initiate communication error resolving process even if a connection between server and client breaks unexpectedly. This is unnecessary action because client nodes are not important for cluster stability. We should ignore communication errors for client and daemon nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9492) Limit number of threads which process SingleMessage with exchangeId==null
Pavel Kovalenko created IGNITE-9492: --- Summary: Limit number of threads which process SingleMessage with exchangeId==null Key: IGNITE-9492 URL: https://issues.apache.org/jira/browse/IGNITE-9492 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.7 Currently, after each PME coordinator spend a lot of time on processing correcting Single messages (with exchange id == null). This leads to growing inbound/outbound messages queue and delaying other coordinator-aware processes. Processing single messages with exchange id == null are not so important to give all available resources to it. We should limit the number of sys-threads which are able to process such single messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9161) CPP: Get rid of additional copy on Get
[
https://issues.apache.org/jira/browse/IGNITE-9161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607045#comment-16607045
]
ASF GitHub Bot commented on IGNITE-9161:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4476
> CPP: Get rid of additional copy on Get
> --
>
> Key: IGNITE-9161
> URL: https://issues.apache.org/jira/browse/IGNITE-9161
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: cpp
> Fix For: 2.7
>
>
> Currently, helper classes from {{operations.h}} header file, e.g.
> {{Out1Operation}} contain additional value, that can't be optimized-out by
> the compiler on return, even though the operation itself is a temporary
> object.
> As a solution, such classes should accept and operate on a reference to a
> temporary object, so that [copy
> elision|https://en.wikipedia.org/wiki/Copy_elision] can be used by a compiler.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9491) Exchange latch coordinator shouldn't be oldest node in a cluster
Pavel Kovalenko created IGNITE-9491: --- Summary: Exchange latch coordinator shouldn't be oldest node in a cluster Key: IGNITE-9491 URL: https://issues.apache.org/jira/browse/IGNITE-9491 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.7 Currently, we have a lot of components having coordinator election ability. Each of these components is electing the oldest node as coordinator. It leads to overloading the oldest node and may be a cause of delaying of some processes. The oldest node can have large inbound/outbound messages queue in large topologies which leads to delaying of processing Exchange Latch Ack messages. We should choose secondary oldest node as coordinator to unload the oldest coordinator. This change will significantly accelerate exchange latch waiting process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7679) Move all test plugins to a separate module
[
https://issues.apache.org/jira/browse/IGNITE-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606971#comment-16606971
]
Maxim Muzafarov edited comment on IGNITE-7679 at 9/7/18 11:41 AM:
--
Folks,
I've attached a link to the discussion on dev.list.
I think we can also move `{{PageMemory tracker plugin 1.0}}` to an
`{{extdata}}` directory.
As for an example, we can take `{{PlatformTestPlugin}}` and this PR
[IGNITE-5879 .NET: Move
TestPlatformPlugin|https://github.com/apache/ignite/pull/2455/files]
was (Author: mmuzaf):
Folks,
I've attached a link to the discussion on dev.list.
I think we can also move `{{PageMemory tracker plugin 1.0}}` to an
`{{extdata}}` directory.
As for an example, we can take `{{PlatformTestPlugin}}` and this PR
[IGNITE- Extend .NET plugin
API|https://github.com/apache/ignite/pull/1480/files]
> Move all test plugins to a separate module
> --
>
> Key: IGNITE-7679
> URL: https://issues.apache.org/jira/browse/IGNITE-7679
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Govorukhin
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> Curretly all test run with plugins (TestReconnectPlugin
> 1.0,StanByClusterTestProvider 1.0, because it is in classpath), this makes
> the tests not clean.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7527) SQL system view for current node transactions
[ https://issues.apache.org/jira/browse/IGNITE-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7527: Ignite Flags: Docs Required > SQL system view for current node transactions > - > > Key: IGNITE-7527 > URL: https://issues.apache.org/jira/browse/IGNITE-7527 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13 > Fix For: 2.7 > > > Implement SQL system view to show active transactions on local node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9366) SQL system view for node metrics
[
https://issues.apache.org/jira/browse/IGNITE-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607004#comment-16607004
]
ASF GitHub Bot commented on IGNITE-9366:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4615
> SQL system view for node metrics
>
>
> Key: IGNITE-9366
> URL: https://issues.apache.org/jira/browse/IGNITE-9366
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-13
> Fix For: 2.7
>
>
> Implement SQL system view to show metrics of each node (information is
> available locally on each node). View must contain NODE_ID column and the
> same set of metrics as provided by {{ClusterMetrics}} interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9355) Document new system views (nodes, node attributes, baseline nodes, node metrics)
[
https://issues.apache.org/jira/browse/IGNITE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-9355:
---
Assignee: Artem Budnikov
> Document new system views (nodes, node attributes, baseline nodes, node
> metrics)
>
>
> Key: IGNITE-9355
> URL: https://issues.apache.org/jira/browse/IGNITE-9355
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document three new SQL system views.
> # Explain users that new system SQL schema appeared, named "IGNITE", where
> all views are stored
> # System view NODES - list of current nodes in topology. Columns: ID,
> CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER,
> ADDRESSES, HOSTNAMES
> # System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID,
> NAME, VALUE
> # System view BASELINE_NODES - list of baseline topology nodes. Columns:
> CONSISTENT_ID, ONLINE (whether node is up and running at the moment)
> # System view NODE_METRICS - node metrics. Columns - see
> \{{org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewNodeMetrics}}
> class
> # Explain limitations: views cannot be joined with user tables; it is not
> allowed to create other objects (tables, indexes) in "IGNITE" schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9355) Document new system views (nodes, node attributes, baseline nodes, node metrics)
[
https://issues.apache.org/jira/browse/IGNITE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9355:
Description:
We need to document three new SQL system views.
# Explain users that new system SQL schema appeared, named "IGNITE", where all
views are stored
# System view NODES - list of current nodes in topology. Columns: ID,
CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER, ADDRESSES,
HOSTNAMES
# System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID,
NAME, VALUE
# System view BASELINE_NODES - list of baseline topology nodes. Columns:
CONSISTENT_ID, ONLINE (whether node is up and running at the moment)
# System view NODE_METRICS - node metrics. Columns - see
\{{org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewNodeMetrics}}
class
# Explain limitations: views cannot be joined with user tables; it is not
allowed to create other objects (tables, indexes) in "IGNITE" schema.
was:
We need to document three new SQL system views.
# Explain users that new system SQL schema appeared, named "IGNITE", where all
views are stored
# System view NODES - list of current nodes in topology. Columns: ID,
CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER, ADDRESSES,
HOSTNAMES
# System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID,
NAME, VALUE
# System view BASELINE_NODES - list of baseline topology nodes. Columns:
CONSISTENT_ID, ONLINE (whether node is up and running at the moment)
# Explain limitations: views cannot be joined with user tables; it is not
allowed to create other objects (tables, indexes) in "IGNITE" schema.
> Document new system views (nodes, node attributes, baseline nodes, node
> metrics)
>
>
> Key: IGNITE-9355
> URL: https://issues.apache.org/jira/browse/IGNITE-9355
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document three new SQL system views.
> # Explain users that new system SQL schema appeared, named "IGNITE", where
> all views are stored
> # System view NODES - list of current nodes in topology. Columns: ID,
> CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER,
> ADDRESSES, HOSTNAMES
> # System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID,
> NAME, VALUE
> # System view BASELINE_NODES - list of baseline topology nodes. Columns:
> CONSISTENT_ID, ONLINE (whether node is up and running at the moment)
> # System view NODE_METRICS - node metrics. Columns - see
> \{{org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewNodeMetrics}}
> class
> # Explain limitations: views cannot be joined with user tables; it is not
> allowed to create other objects (tables, indexes) in "IGNITE" schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9355) Document new system views (nodes, node attributes, baseline nodes, node attributes)
[ https://issues.apache.org/jira/browse/IGNITE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9355: Summary: Document new system views (nodes, node attributes, baseline nodes, node attributes) (was: Document 3 new system views (nodes, node attributes, baseline nodes)) > Document new system views (nodes, node attributes, baseline nodes, node > attributes) > --- > > Key: IGNITE-9355 > URL: https://issues.apache.org/jira/browse/IGNITE-9355 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > We need to document three new SQL system views. > # Explain users that new system SQL schema appeared, named "IGNITE", where > all views are stored > # System view NODES - list of current nodes in topology. Columns: ID, > CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER, > ADDRESSES, HOSTNAMES > # System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID, > NAME, VALUE > # System view BASELINE_NODES - list of baseline topology nodes. Columns: > CONSISTENT_ID, ONLINE (whether node is up and running at the moment) > # Explain limitations: views cannot be joined with user tables; it is not > allowed to create other objects (tables, indexes) in "IGNITE" schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9355) Document new system views (nodes, node attributes, baseline nodes, node metrics)
[ https://issues.apache.org/jira/browse/IGNITE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9355: Summary: Document new system views (nodes, node attributes, baseline nodes, node metrics) (was: Document new system views (nodes, node attributes, baseline nodes, node attributes)) > Document new system views (nodes, node attributes, baseline nodes, node > metrics) > > > Key: IGNITE-9355 > URL: https://issues.apache.org/jira/browse/IGNITE-9355 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > We need to document three new SQL system views. > # Explain users that new system SQL schema appeared, named "IGNITE", where > all views are stored > # System view NODES - list of current nodes in topology. Columns: ID, > CONSISTENT_ID, VERSION, IS_LOCAL, IS_CLIENT, IS_DAEMON, NODE_ORDER, > ADDRESSES, HOSTNAMES > # System view NODE_ATTRIBUTES - attributes for all nodes. Columns: NODE_ID, > NAME, VALUE > # System view BASELINE_NODES - list of baseline topology nodes. Columns: > CONSISTENT_ID, ONLINE (whether node is up and running at the moment) > # Explain limitations: views cannot be joined with user tables; it is not > allowed to create other objects (tables, indexes) in "IGNITE" schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7679) Move all test plugins to a separate module
[
https://issues.apache.org/jira/browse/IGNITE-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606971#comment-16606971
]
Maxim Muzafarov commented on IGNITE-7679:
-
Folks,
I've attached a link to the discussion on dev.list.
I think we can also move `{{PageMemory tracker plugin 1.0}}` to an
`{{extdata}}` directory.
As for an example, we can take `{{PlatformTestPlugin}}` and this PR
[IGNITE- Extend .NET plugin
API|https://github.com/apache/ignite/pull/1480/files]
> Move all test plugins to a separate module
> --
>
> Key: IGNITE-7679
> URL: https://issues.apache.org/jira/browse/IGNITE-7679
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Govorukhin
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> Curretly all test run with plugins (TestReconnectPlugin
> 1.0,StanByClusterTestProvider 1.0, because it is in classpath), this makes
> the tests not clean.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9482) [ML] Refactor all trainers' settters to withFieldName format for meta-algorithms
[ https://issues.apache.org/jira/browse/IGNITE-9482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606963#comment-16606963 ] ASF GitHub Bot commented on IGNITE-9482: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4699 > [ML] Refactor all trainers' settters to withFieldName format for > meta-algorithms > > > Key: IGNITE-9482 > URL: https://issues.apache.org/jira/browse/IGNITE-9482 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.7 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7679) Move all test plugins to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7679: Labels: newbie (was: ) > Move all test plugins to a separate module > -- > > Key: IGNITE-7679 > URL: https://issues.apache.org/jira/browse/IGNITE-7679 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Govorukhin >Priority: Major > Labels: newbie > Fix For: 2.8 > > > Curretly all test run with plugins (TestReconnectPlugin > 1.0,StanByClusterTestProvider 1.0, because it is in classpath), this makes > the tests not clean. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
