[jira] [Commented] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380339#comment-17380339 ] Vibhuti Sawant commented on IGNITE-14017: - Hi [~vveider] Any update on this? > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.12 > > Attachments: Dockerfile > > Time Spent: 20m > Remaining Estimate: 0h > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15116) SQL tests for extension to write CDC data to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-15116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380209#comment-17380209 ] Maxim Muzafarov commented on IGNITE-15116: -- [~nizhikov] Changes look good to me. > SQL tests for extension to write CDC data to Kafka > -- > > Key: IGNITE-15116 > URL: https://issues.apache.org/jira/browse/IGNITE-15116 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Tests should be extended to cover replication of SQL tables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15116) SQL tests for extension to write CDC data to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-15116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-15116: - Component/s: extensions > SQL tests for extension to write CDC data to Kafka > -- > > Key: IGNITE-15116 > URL: https://issues.apache.org/jira/browse/IGNITE-15116 > Project: Ignite > Issue Type: Improvement > Components: extensions >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Tests should be extended to cover replication of SQL tables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15103:
-
Description:
Currently, there is no logging at all, should be added using {{logging}} module
was:
Currently, there is no logging at all, should be added using {{logging}} module
Also, optional handler to {{stderr}} should be added if env variable is set,
[i.e.|https://github.com/aio-libs/aioredis-py/blob/bb0dcebed350a5f764dc84c5b6bcb44a3bf98c6b/aioredis/log.py]
{code:python}
logger = logging.getLogger("pyignite")
if os.environ.get("PYIGNITE_DEBUG"):
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler(stream=sys.stderr)
handler.setFormatter(
logging.Formatter("%(asctime)s %(name)s %(levelname)s %(message)s")
)
logger.addHandler(handler)
os.environ["PYIGNITE_DEBUG"] = ""
{code}
> Add logging to pyignite client
> --
>
> Key: IGNITE-15103
> URL: https://issues.apache.org/jira/browse/IGNITE-15103
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, there is no logging at all, should be added using {{logging}}
> module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380159#comment-17380159
]
Ivan Daschinsky edited comment on IGNITE-15103 at 7/13/21, 8:34 PM:
Example of logging output
{code}
2021-07-13 22:11:08,631 pyignite.connection DEBUG Connecting to
node(address=127.0.0.1, port=10801) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,645 pyignite.connection DEBUG Connected to
node(address=127.0.0.1, port=10801,
node_uuid=60ff4be9-d14c-4973-bce8-1c634afc587d) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,646 pyignite.connection DEBUG Connecting to
node(address=127.0.0.1, port=10802) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,677 pyignite.connection DEBUG Connected to
node(address=127.0.0.1, port=10802,
node_uuid=5a6d4e3f-e202-404a-9670-cb1bbd5029be) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,678 pyignite.queries DEBUG Start query(query_id=6436,
op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:08,685 pyignite.queries DEBUG Finished
query(query_id=6436, op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 7.000 ms
2021-07-13 22:11:08,686 pyignite.queries DEBUG Start query(query_id=6437,
op_type=OP_CLUSTER_CHANGE_STATE, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:08,689 pyignite.queries DEBUG Finished
query(query_id=6437, op_type=OP_CLUSTER_CHANGE_STATE, host=127.0.0.1,
port=10801, node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 3.000
ms
2021-07-13 22:11:08,690 pyignite.queries DEBUG Start query(query_id=6438,
op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be)
2021-07-13 22:11:08,697 pyignite.queries DEBUG Finished
query(query_id=6438, op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be) successfully in 7.000 ms
2021-07-13 22:11:09,887 pyignite.queries DEBUG Start query(query_id=6486,
op_type=OP_CACHE_PARTITIONS, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be)
2021-07-13 22:11:09,948 pyignite.queries DEBUG Finished
query(query_id=6486, op_type=OP_CACHE_PARTITIONS, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be) successfully in 60.000 ms
2021-07-13 22:11:09,948 pyignite.queries DEBUG Start query(query_id=6487,
op_type=OP_CACHE_PUT, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:09,951 pyignite.queries DEBUG Finished
query(query_id=6487, op_type=OP_CACHE_PUT, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 3.000 ms
2021-07-13 22:11:09,952 pyignite.queries DEBUG Start query(query_id=6488,
op_type=OP_CACHE_GET, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:09,954 pyignite.queries DEBUG Finished
query(query_id=6488, op_type=OP_CACHE_GET, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 1.000 ms
2021-07-13 22:11:09,954 pyignite.connection DEBUG Connection closed to
node(address=127.0.0.1, port=10801,
node_uuid=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:09,954 pyignite.connection DEBUG Connection closed to
node(address=127.0.0.1, port=10802,
node_uuid=5a6d4e3f-e202-404a-9670-cb1bbd5029be)
{code}
{code}
2021-07-13 22:12:34,588 pyignite.connection DEBUG Connecting to
node(address=127.0.0.1, port=10801) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:12:34,628 pyignite.connection ERROR Authentication failed
while connecting to node(address=127.0.0.1, port=10801): The user name or
password is incorrect [userName=null]
{code}
{code}
2021-07-13 22:13:27,969 pyignite.connection DEBUG Connecting to
node(address=127.0.0.1, port=10801) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:13:27,972 pyignite.connection ERROR Failed to perform
handshake, connection to node(address=127.0.0.1, port=10801) with protocol
context None failed: Connection broken.
{code}
was (Author: ivandasch):
Example of logging output
{code}
2021-07-13 22:11:08,631 pyignite.connection DEBUG Connecting to
node(address=127.0.0.1, port=10801) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,645
[jira] [Commented] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380159#comment-17380159
]
Ivan Daschinsky commented on IGNITE-15103:
--
Example of logging output
{code}
2021-07-13 22:11:08,631 pyignite.connection DEBUG Connecting to
node(address=127.0.0.1, port=10801) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,645 pyignite.connection DEBUG Connected to
node(address=127.0.0.1, port=10801,
node_uuid=60ff4be9-d14c-4973-bce8-1c634afc587d) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,646 pyignite.connection DEBUG Connecting to
node(address=127.0.0.1, port=10802) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,677 pyignite.connection DEBUG Connected to
node(address=127.0.0.1, port=10802,
node_uuid=5a6d4e3f-e202-404a-9670-cb1bbd5029be) with protocol context
ProtocolContext(version=(1, 7, 0), features=BitmaskFeature.CLUSTER_API)
2021-07-13 22:11:08,678 pyignite.queries DEBUG Start query(query_id=6436,
op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:08,685 pyignite.queries DEBUG Finished
query(query_id=6436, op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 7.000 ms
2021-07-13 22:11:08,686 pyignite.queries DEBUG Start query(query_id=6437,
op_type=OP_CLUSTER_CHANGE_STATE, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:08,689 pyignite.queries DEBUG Finished
query(query_id=6437, op_type=OP_CLUSTER_CHANGE_STATE, host=127.0.0.1,
port=10801, node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 3.000
ms
2021-07-13 22:11:08,690 pyignite.queries DEBUG Start query(query_id=6438,
op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be)
2021-07-13 22:11:08,697 pyignite.queries DEBUG Finished
query(query_id=6438, op_type=OP_CLUSTER_GET_STATE, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be) successfully in 7.000 ms
2021-07-13 22:11:09,887 pyignite.queries DEBUG Start query(query_id=6486,
op_type=OP_CACHE_PARTITIONS, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be)
2021-07-13 22:11:09,948 pyignite.queries DEBUG Finished
query(query_id=6486, op_type=OP_CACHE_PARTITIONS, host=127.0.0.1, port=10802,
node_id=5a6d4e3f-e202-404a-9670-cb1bbd5029be) successfully in 60.000 ms
2021-07-13 22:11:09,948 pyignite.queries DEBUG Start query(query_id=6487,
op_type=OP_CACHE_PUT, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:09,951 pyignite.queries DEBUG Finished
query(query_id=6487, op_type=OP_CACHE_PUT, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 3.000 ms
2021-07-13 22:11:09,952 pyignite.queries DEBUG Start query(query_id=6488,
op_type=OP_CACHE_GET, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:09,954 pyignite.queries DEBUG Finished
query(query_id=6488, op_type=OP_CACHE_GET, host=127.0.0.1, port=10801,
node_id=60ff4be9-d14c-4973-bce8-1c634afc587d) successfully in 1.000 ms
2021-07-13 22:11:09,954 pyignite.connection DEBUG Connection closed to
node(address=127.0.0.1, port=10801,
node_uuid=60ff4be9-d14c-4973-bce8-1c634afc587d)
2021-07-13 22:11:09,954 pyignite.connection DEBUG Connection closed to
node(address=127.0.0.1, port=10802,
node_uuid=5a6d4e3f-e202-404a-9670-cb1bbd5029be)
{code}
> Add logging to pyignite client
> --
>
> Key: IGNITE-15103
> URL: https://issues.apache.org/jira/browse/IGNITE-15103
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, there is no logging at all, should be added using {{logging}}
> module
> Also, optional handler to {{stderr}} should be added if env variable is set,
> [i.e.|https://github.com/aio-libs/aioredis-py/blob/bb0dcebed350a5f764dc84c5b6bcb44a3bf98c6b/aioredis/log.py]
> {code:python}
> logger = logging.getLogger("pyignite")
> if os.environ.get("PYIGNITE_DEBUG"):
> logger.setLevel(logging.DEBUG)
> handler = logging.StreamHandler(stream=sys.stderr)
> handler.setFormatter(
> logging.Formatter("%(asctime)s %(name)s %(levelname)s %(message)s")
> )
> logger.addHandler(handler)
> os.environ["PYIGNITE_DEBUG"] = ""
> {code}
[jira] [Updated] (IGNITE-15117) Support CDC for in-memory caches
[ https://issues.apache.org/jira/browse/IGNITE-15117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-15117: - Summary: Support CDC for in-memory caches (was: Support WAL enabling for in-memory caches) > Support CDC for in-memory caches > > > Key: IGNITE-15117 > URL: https://issues.apache.org/jira/browse/IGNITE-15117 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Right now CDC is supported only for persistent caches. > To support CDC feature for in-memory caches we should support enabling WAL > for in-memory caches. > Only DataRecord is required for CDC so we can write only specific that types > of records to the WAL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15117) Support WAL enabling for in-memory caches
Nikolay Izhikov created IGNITE-15117: Summary: Support WAL enabling for in-memory caches Key: IGNITE-15117 URL: https://issues.apache.org/jira/browse/IGNITE-15117 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Right now CDC is supported only for persistent caches. To support CDC feature for in-memory caches we should support enabling WAL for in-memory caches. Only DataRecord is required for CDC so we can write only specific that types of records to the WAL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15116) SQL tests for extension to write CDC data to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-15116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380105#comment-17380105 ] Nikolay Izhikov commented on IGNITE-15116: -- https://ci.ignite.apache.org/viewLog.html?buildId=6085067=IgniteExtensions_Tests_Cdc - tests > SQL tests for extension to write CDC data to Kafka > -- > > Key: IGNITE-15116 > URL: https://issues.apache.org/jira/browse/IGNITE-15116 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Tests should be extended to cover replication of SQL tables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12747) Calcite integration. Correlated queries support.
[ https://issues.apache.org/jira/browse/IGNITE-12747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny reassigned IGNITE-12747: --- Assignee: (was: Stanilovsky Evgeny) > Calcite integration. Correlated queries support. > > > Key: IGNITE-12747 > URL: https://issues.apache.org/jira/browse/IGNITE-12747 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Priority: Critical > Labels: calcite2-required, calcite3-required > Time Spent: 4h 10m > Remaining Estimate: 0h > > Rewrite correlated subqueries. > Useful links: > [https://zhuanlan.zhihu.com/p/60380557] > [https://zhuanlan.zhihu.com/p/62338250] > [https://zhuanlan.zhihu.com/p/66227661] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12747) Calcite integration. Correlated queries support.
[ https://issues.apache.org/jira/browse/IGNITE-12747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379968#comment-17379968 ] Stanilovsky Evgeny commented on IGNITE-12747: - some correlate functionality merged in scope of [1], this issue seems need additional tests to be added. [1] https://issues.apache.org/jira/browse/IGNITE-13159 > Calcite integration. Correlated queries support. > > > Key: IGNITE-12747 > URL: https://issues.apache.org/jira/browse/IGNITE-12747 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Stanilovsky Evgeny >Priority: Critical > Labels: calcite2-required, calcite3-required > Time Spent: 4h 10m > Remaining Estimate: 0h > > Rewrite correlated subqueries. > Useful links: > [https://zhuanlan.zhihu.com/p/60380557] > [https://zhuanlan.zhihu.com/p/62338250] > [https://zhuanlan.zhihu.com/p/66227661] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379945#comment-17379945 ] Pavel Tupitsyn edited comment on IGNITE-11704 at 7/13/21, 2:59 PM: --- TC run above is for https://github.com/apache/ignite/pull/9249: "IGNITE-11704 Add PARTITION_META_PAGE_DELTA_RECORD_V4 WALRecord type placeholder" Merged to master: 97edc893d5c6bcd458364746c5624a0bf9d1ae81 was (Author: ptupitsyn): TC run above is for https://github.com/apache/ignite/pull/9249: "IGNITE-11704 Add PARTITION_META_PAGE_DELTA_RECORD_V4 WALRecord type placeholder" > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Scherbakov >Priority: Major > Labels: rebalance > Time Spent: 50m > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379945#comment-17379945 ] Pavel Tupitsyn commented on IGNITE-11704: - TC run above is for https://github.com/apache/ignite/pull/9249: "IGNITE-11704 Add PARTITION_META_PAGE_DELTA_RECORD_V4 WALRecord type placeholder" > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Scherbakov >Priority: Major > Labels: rebalance > Time Spent: 40m > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14537) Calcite engine. Nested arbitrary queries hangs on optimizing
[
https://issues.apache.org/jira/browse/IGNITE-14537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov resolved IGNITE-14537.
---
Resolution: Duplicate
Fixed by IGNITE-13159
> Calcite engine. Nested arbitrary queries hangs on optimizing
> --
>
> Key: IGNITE-14537
> URL: https://issues.apache.org/jira/browse/IGNITE-14537
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> The query with nested arbitrary subqueries aren't planned.
> Test: {{subquery/test_neumann.test_ignore}}
> See more: [Unnesting Arbitrary
> Queries|https://subs.emis.de/LNI/Proceedings/Proceedings241/383.pdf]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13159) Calcite integration. Decorrelator support SOME and ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-13159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-13159:
--
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite integration. Decorrelator support SOME and ALL operator.
>
>
> Key: IGNITE-13159
> URL: https://issues.apache.org/jira/browse/IGNITE-13159
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Labels: calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now Calcite SqlToRelConverter throws an exception if found a subquery in
> ALL\SOME operator. See SubqueryRewriteRuleTest.testNonAllToSemiAntiJoinRule
> test and find stack trace below.
> We have to either set flag "expand=false" and implement LogicalCorrelate
> converter
> or some rules to overcome the issue.
> However, setting flag "expand=false" makes query pass, but with wrong join
> type (left and inner instead of anti) and moreover it brakes other queries
> due to weird decorrelator behavior. Possibly there is bug in Calcite.
> {code:java}
> Caused by: java.lang.RuntimeException: ALL is only supported if expand =
> falseCaused by: java.lang.RuntimeException: ALL is only supported if expand =
> false at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4814)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1016)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:662)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:640)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3384)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:566)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:203)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.optimize(ExecutionServiceImpl.java:618)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareExplain(ExecutionServiceImpl.java:644)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:573)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepare0(ExecutionServiceImpl.java:531)
> ... 16 more
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15106) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-15106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauricio Stekl reassigned IGNITE-15106: --- Assignee: Mauricio Stekl > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-15106 > URL: https://issues.apache.org/jira/browse/IGNITE-15106 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Trivial > > Please add an event to [https://ignite.apache.org/events.html] > > Apache Ignite 3.0.0 Alpha 2 Build Community Gathering > Virtual Apache Ignite Meetup, Valentin Kulichenko > June 20 > This gathering is organized to summarize feedback, share ideas, and overview > the following stages of Ignite 3.0 development. > During this session, we will: > ‒ Give an update on the Ignite 3 development - what has been completed so > far, and the next steps planned. > ‒ Discuss the latest Ignite 3 milestone: the Alpha 2 release. > ‒ Run a live demo: create an Ignite 3 Alpha 2 cluster and demonstrate the new > APIs usage by running code examples. > Learn > more=https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/279417063/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15093) MVP for transactional protocol
[ https://issues.apache.org/jira/browse/IGNITE-15093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15093: --- Summary: MVP for transactional protocol (was: MVP for transactional protocol (first version)) > MVP for transactional protocol > -- > > Key: IGNITE-15093 > URL: https://issues.apache.org/jira/browse/IGNITE-15093 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > > It is necessary to develop an MVP for transactional protocol components. > It seems we need at least IGNITE-15083 IGNITE-15085 IGNITE-15086 and > IGNITE-15057 for this. > The simplest implementation will do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15114) Design and implement the process of a node joining a cluster
[ https://issues.apache.org/jira/browse/IGNITE-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-15114: - Fix Version/s: 3.0 > Design and implement the process of a node joining a cluster > > > Key: IGNITE-15114 > URL: https://issues.apache.org/jira/browse/IGNITE-15114 > Project: Ignite > Issue Type: Epic >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > The target of this epic is to design and implement a protocol for a node to > join a cluster and exchange some information before being either allowed or > prohibited from entering the topology. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15116) SQL tests for extension to write CDC data to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-15116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-15116: - Description: Tests should be extended to cover replication of SQL tables. (was: Tests should be extended to cover REPLICATED vs. PARTITIONED caches.) > SQL tests for extension to write CDC data to Kafka > -- > > Key: IGNITE-15116 > URL: https://issues.apache.org/jira/browse/IGNITE-15116 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Tests should be extended to cover replication of SQL tables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15116) SQL tests for extension to write CDC data to Kafka
Nikolay Izhikov created IGNITE-15116: Summary: SQL tests for extension to write CDC data to Kafka Key: IGNITE-15116 URL: https://issues.apache.org/jira/browse/IGNITE-15116 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Tests should be extended to cover REPLICATED vs. PARTITIONED caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14519) Add ability to remove event handlers
[
https://issues.apache.org/jira/browse/IGNITE-14519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14519:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add ability to remove event handlers
>
>
> Key: IGNITE-14519
> URL: https://issues.apache.org/jira/browse/IGNITE-14519
> Project: Ignite
> Issue Type: Improvement
> Components: networking
>Reporter: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
>
> {{Both TopologyService and }}{{MessagingService}} allow registering event
> handlers. They should also allow removing registered handlers by dynamically
> loaded components (e.g. caches) in order to avoid memory leaks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13159) Calcite integration. Decorrelator support SOME and ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-13159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379867#comment-17379867
]
Stanilovsky Evgeny commented on IGNITE-13159:
-
[~tledkov-gridgain] can u merge it plz ? thanks !
> Calcite integration. Decorrelator support SOME and ALL operator.
>
>
> Key: IGNITE-13159
> URL: https://issues.apache.org/jira/browse/IGNITE-13159
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now Calcite SqlToRelConverter throws an exception if found a subquery in
> ALL\SOME operator. See SubqueryRewriteRuleTest.testNonAllToSemiAntiJoinRule
> test and find stack trace below.
> We have to either set flag "expand=false" and implement LogicalCorrelate
> converter
> or some rules to overcome the issue.
> However, setting flag "expand=false" makes query pass, but with wrong join
> type (left and inner instead of anti) and moreover it brakes other queries
> due to weird decorrelator behavior. Possibly there is bug in Calcite.
> {code:java}
> Caused by: java.lang.RuntimeException: ALL is only supported if expand =
> falseCaused by: java.lang.RuntimeException: ALL is only supported if expand =
> false at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4814)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1016)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:662)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:640)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3384)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:566)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:203)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.optimize(ExecutionServiceImpl.java:618)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareExplain(ExecutionServiceImpl.java:644)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:573)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepare0(ExecutionServiceImpl.java:531)
> ... 16 more
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15086) Design a public tx API
[
https://issues.apache.org/jira/browse/IGNITE-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379861#comment-17379861
]
Alexey Scherbakov commented on IGNITE-15086:
Transaction examples can be found here [1]
Additionaly, the PR includes some code to propagate tx context into
InternalTable, which later will be used to build up a transactional execution.
[1]
https://github.com/apache/ignite-3/blob/d2a0003ac69058cddc36a1a6c8a57ada772ccff1/modules/table/src/test/java/org/apache/ignite/internal/table/TxTest.java
> Design a public tx API
> --
>
> Key: IGNITE-15086
> URL: https://issues.apache.org/jira/browse/IGNITE-15086
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: iep-61, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Design a public tx API.
> The proposed design includes async and sync APIs to execute a transaction.
> The transaction facade looks like this:
> {code}
> /**
> * Ignite Transactions facade.
> */
> public interface IgniteTransactions {
> /**
> * Begins the transaction.
> *
> * @return The future.
> */
> CompletableFuture beginAsync();
> /**
> * Synchronously executes a closure within a transaction.
> *
> * @param clo The closure.
> */
> void runInTransaction(Consumer clo);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15086) Design a public tx API
[
https://issues.apache.org/jira/browse/IGNITE-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-15086:
---
Description:
Design a public tx API.
The proposed design includes async and sync APIs to execute a transaction.
The transaction facade looks like this:
{code}
/**
* Ignite Transactions facade.
*/
public interface IgniteTransactions {
/**
* Begins the transaction.
*
* @return The future.
*/
CompletableFuture beginAsync();
/**
* Synchronously executes a closure within a transaction.
*
* @param clo The closure.
*/
void runInTransaction(Consumer clo);
}
{code}
was:Design a public tx API.
> Design a public tx API
> --
>
> Key: IGNITE-15086
> URL: https://issues.apache.org/jira/browse/IGNITE-15086
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: iep-61, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Design a public tx API.
> The proposed design includes async and sync APIs to execute a transaction.
> The transaction facade looks like this:
> {code}
> /**
> * Ignite Transactions facade.
> */
> public interface IgniteTransactions {
> /**
> * Begins the transaction.
> *
> * @return The future.
> */
> CompletableFuture beginAsync();
> /**
> * Synchronously executes a closure within a transaction.
> *
> * @param clo The closure.
> */
> void runInTransaction(Consumer clo);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379834#comment-17379834 ] Eduard Rakhmankulov commented on IGNITE-14728: -- [~alapin] please take a look. > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Assignee: Eduard Rakhmankulov >Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most part > of users. > I propose the creation of a new DMS property *history.rebalance.threshold* > instead of a system property. > The next algorithm will be used: > # On node start *history.rebalance.threshold* property will be checked. > # If there is no value, then the old system property > *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. > # If a system property is not defined then the default value from java will > be written to DMS (*500*). > # On property check print to log value and source of value. > Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. > Dev list discussion > [http://apache-ignite-developers.2346864.n4.nabble.com/Change-IGNITE-PDS-WAL-REBALANCE-THRESHOLD-from-System-property-to-Configuraton-tp52560.html] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[
https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379826#comment-17379826
]
Ignite TC Bot commented on IGNITE-14728:
{panel:title=Branch: [pull/9248/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9248/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6083355]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerPropertiesTest.testPropertyWalRebalanceThreshold -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6083363buildTypeId=IgniteTests24Java8_RunAll]
> Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed
> property
> --
>
> Key: IGNITE-14728
> URL: https://issues.apache.org/jira/browse/IGNITE-14728
> Project: Ignite
> Issue Type: Improvement
>Reporter: Eduard Rakhmankulov
>Assignee: Eduard Rakhmankulov
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that
> determines a count of entries of partition starting from which cluster will
> try applying historical rebalance for that partition.
> But the system property is not convenient to use and is hidden from most part
> of users.
> I propose the creation of a new DMS property *history.rebalance.threshold*
> instead of a system property.
> The next algorithm will be used:
> # On node start *history.rebalance.threshold* property will be checked.
> # If there is no value, then the old system property
> *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS.
> # If a system property is not defined then the default value from java will
> be written to DMS (*500*).
> # On property check print to log value and source of value.
> Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated.
> Dev list discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/Change-IGNITE-PDS-WAL-REBALANCE-THRESHOLD-from-System-property-to-Configuraton-tp52560.html]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[
https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379825#comment-17379825
]
Ignite TC Bot commented on IGNITE-11704:
{panel:title=Branch: [pull/9249/head] Base: [master] : Possible Blockers
(9)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility (Zookeeper){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6084190]]
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6084174]]
* exe: CacheTest.TestCacheWithExpiryPolicyOnAccess - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6084136]]
* IgniteBasicTestSuite: WALRecordTest.testAllTestWalRecordBuilderConfigured -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBasicTestSuite:
WALRecordSerializationTest.testAllWalRecordsSerializedAndDeserializedSuccessfully
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6084172]]
{color:#d04437}Java Client{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6084115]]
{color:#d04437}Cache (Failover) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6084144]]
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6084171]]
* exe: DataStorageMetricsTest.TestDataStorageMetrics - Test has low fail rate
in base branch 0,0% and is not flaky
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6084193]]
{panel}
{panel:title=Branch: [pull/9249/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6084165]]
* {color:#013220}IgnitePdsWithIndexingTestSuite:
RenameIndexTreeTest.testNotPersistRenamingIndexRootPage - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
RenameIndexTreeTest.testPersistRenamingIndexRootPage - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
RenameIndexTreeTest.testRenamingIndexRootPage - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6084197buildTypeId=IgniteTests24Java8_RunAll]
> Write tombstones during rebalance to get rid of deferred delete buffer
> --
>
> Key: IGNITE-11704
> URL: https://issues.apache.org/jira/browse/IGNITE-11704
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: rebalance
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently Ignite relies on deferred delete buffer in order to handle
> write-remove conflicts during rebalance. Given the limit size of the buffer,
> this approach is fundamentally flawed, especially in case when persistence is
> enabled.
> I suggest to extend the logic of data storage to be able to store key
> tombstones - to keep version for deleted entries. The tombstones will be
> stored when rebalance is in progress and should be cleaned up when rebalance
> is completed.
> Later this approach may be used to implement fast partition rebalance based
> on merkle trees (in this case, tombstones should be written on an incomplete
> baseline).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13159) Calcite integration. Decorrelator support SOME and ALL operator.
[
https://issues.apache.org/jira/browse/IGNITE-13159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny reassigned IGNITE-13159:
---
Assignee: Stanilovsky Evgeny
> Calcite integration. Decorrelator support SOME and ALL operator.
>
>
> Key: IGNITE-13159
> URL: https://issues.apache.org/jira/browse/IGNITE-13159
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Labels: calcite2-required, calcite3-required
>
> Now Calcite SqlToRelConverter throws an exception if found a subquery in
> ALL\SOME operator. See SubqueryRewriteRuleTest.testNonAllToSemiAntiJoinRule
> test and find stack trace below.
> We have to either set flag "expand=false" and implement LogicalCorrelate
> converter
> or some rules to overcome the issue.
> However, setting flag "expand=false" makes query pass, but with wrong join
> type (left and inner instead of anti) and moreover it brakes other queries
> due to weird decorrelator behavior. Possibly there is bug in Calcite.
> {code:java}
> Caused by: java.lang.RuntimeException: ALL is only supported if expand =
> falseCaused by: java.lang.RuntimeException: ALL is only supported if expand =
> false at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4814)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1016)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:662)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:640)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3384)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:566)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:203)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.optimize(ExecutionServiceImpl.java:618)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareExplain(ExecutionServiceImpl.java:644)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:573)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepare0(ExecutionServiceImpl.java:531)
> ... 16 more
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15105) Reduce number of messages for "Blocked system-critical thread" errors
[ https://issues.apache.org/jira/browse/IGNITE-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379778#comment-17379778 ] Ivan Bessonov commented on IGNITE-15105: Mistakenly committed with "GG-30086 Reduce number of messages for "Blocked system-critical thread"" commit message. There's no point of reverting it at this point because this won't give us clean commit history. My bad. > Reduce number of messages for "Blocked system-critical thread" errors > - > > Key: IGNITE-15105 > URL: https://issues.apache.org/jira/browse/IGNITE-15105 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > Now, we're printing a lot of messages for these errors, each of them has > thousands of lines, because it prints locks and/or threads. It overwrites > everything else in logs and makes troubleshooting impossible. > This behavior was analyzed on 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14748:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14748:
---
Labels: iep-55 ignite-3 (was: iep-55)
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14748:
---
Fix Version/s: 3.0.0-alpha3
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15105) Reduce number of messages for "Blocked system-critical thread" errors
[ https://issues.apache.org/jira/browse/IGNITE-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379653#comment-17379653 ] Ivan Bessonov commented on IGNITE-15105: [~apolovtcev] thank you for the contribution! Code looks good, I'll merge it > Reduce number of messages for "Blocked system-critical thread" errors > - > > Key: IGNITE-15105 > URL: https://issues.apache.org/jira/browse/IGNITE-15105 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Now, we're printing a lot of messages for these errors, each of them has > thousands of lines, because it prints locks and/or threads. It overwrites > everything else in logs and makes troubleshooting impossible. > This behavior was analyzed on 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15050) Add rename index tree to drop index
[ https://issues.apache.org/jira/browse/IGNITE-15050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379634#comment-17379634 ] Ivan Bessonov commented on IGNITE-15050: [~ktkale...@gridgain.com] thank you for the contribution, looking forward for the IGNITE-15026 fix. > Add rename index tree to drop index > --- > > Key: IGNITE-15050 > URL: https://issues.apache.org/jira/browse/IGNITE-15050 > Project: Ignite > Issue Type: Improvement > Components: persistence, sql >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > To implement the removal of indices in the > *DurableBackgroundCleanupIndexTreeTask* (IGNITE-15026), at the beginning we > need to rename the index tree, this is not yet available. -- This message was sent by Atlassian Jira (v8.3.4#803005)
