[jira] [Comment Edited] (IGNITE-15076) Calcite. ignite.[sh|bat] node runner script failed to start instance.
[ https://issues.apache.org/jira/browse/IGNITE-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380366#comment-17380366 ] Stanilovsky Evgeny edited comment on IGNITE-15076 at 7/14/21, 6:30 AM: --- [~tledkov-gridgain] it`s safe to merge it into ai-3 too, i hope. was (Author: zstan): [~tledkov-gridgain] it`s safe to marge it into ai-3 too, i hope. > Calcite. ignite.[sh|bat] node runner script failed to start instance. > - > > Key: IGNITE-15076 > URL: https://issues.apache.org/jira/browse/IGNITE-15076 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite, calcite3-required > Time Spent: 0.5h > Remaining Estimate: 0h > > Found that node runner script failed with trace: > {noformat} > java.lang.ExceptionInInitializerError > at > org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:241) > at > org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:217) > at > org.apache.calcite.tools.Frameworks.newConfigBuilder(Frameworks.java:201) > at > org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.(CalciteQueryProcessor.java:73) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at > org.apache.ignite.internal.util.IgniteUtils.inClassPath(IgniteUtils.java:1754) > at > org.apache.ignite.internal.IgniteComponentType.inClassPath(IgniteComponentType.java:181) > at > org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1267) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172) > at > org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) > at org.apache.ignite.Ignition.start(Ignition.java:353) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367) > Caused by: java.lang.NullPointerException > at > sun.reflect.annotation.TypeAnnotationParser.mapTypeAnnotations(TypeAnnotationParser.java:356) > at > sun.reflect.annotation.AnnotatedTypeFactory$AnnotatedTypeBaseImpl.(AnnotatedTypeFactory.java:139) > at > sun.reflect.annotation.AnnotatedTypeFactory.buildAnnotatedType(AnnotatedTypeFactory.java:65) > at > sun.reflect.annotation.TypeAnnotationParser.buildAnnotatedType(TypeAnnotationParser.java:79) > at > java.lang.reflect.Executable.getAnnotatedReturnType0(Executable.java:640) > at java.lang.reflect.Method.getAnnotatedReturnType(Method.java:648) > at > org.apache.calcite.util.ImmutableBeans.makeDef(ImmutableBeans.java:146) > at > org.apache.calcite.util.ImmutableBeans.access$000(ImmutableBeans.java:55) > at > org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:68) > at > org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:65) > at > com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527) > at > com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2276) > at > com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154) > at > com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3973) > at > com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4957) > at > org.apache.calcite.util.ImmutableBeans.create_(ImmutableBeans.java:95) > at > org.apache.calcite.util.ImmutableBeans.create(ImmutableBeans.java:76) > at > org.apache.calcite.sql.validate.SqlValidator$Config.(SqlValidator.java:792) > ... 19 more > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15076) Calcite. ignite.[sh|bat] node runner script failed to start instance.
[ https://issues.apache.org/jira/browse/IGNITE-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380366#comment-17380366 ] Stanilovsky Evgeny commented on IGNITE-15076: - [~tledkov-gridgain] it`s safe to marge it into ai-3 too, i hope. > Calcite. ignite.[sh|bat] node runner script failed to start instance. > - > > Key: IGNITE-15076 > URL: https://issues.apache.org/jira/browse/IGNITE-15076 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite, calcite3-required > Time Spent: 0.5h > Remaining Estimate: 0h > > Found that node runner script failed with trace: > {noformat} > java.lang.ExceptionInInitializerError > at > org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:241) > at > org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:217) > at > org.apache.calcite.tools.Frameworks.newConfigBuilder(Frameworks.java:201) > at > org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.(CalciteQueryProcessor.java:73) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at > org.apache.ignite.internal.util.IgniteUtils.inClassPath(IgniteUtils.java:1754) > at > org.apache.ignite.internal.IgniteComponentType.inClassPath(IgniteComponentType.java:181) > at > org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1267) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172) > at > org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) > at org.apache.ignite.Ignition.start(Ignition.java:353) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367) > Caused by: java.lang.NullPointerException > at > sun.reflect.annotation.TypeAnnotationParser.mapTypeAnnotations(TypeAnnotationParser.java:356) > at > sun.reflect.annotation.AnnotatedTypeFactory$AnnotatedTypeBaseImpl.(AnnotatedTypeFactory.java:139) > at > sun.reflect.annotation.AnnotatedTypeFactory.buildAnnotatedType(AnnotatedTypeFactory.java:65) > at > sun.reflect.annotation.TypeAnnotationParser.buildAnnotatedType(TypeAnnotationParser.java:79) > at > java.lang.reflect.Executable.getAnnotatedReturnType0(Executable.java:640) > at java.lang.reflect.Method.getAnnotatedReturnType(Method.java:648) > at > org.apache.calcite.util.ImmutableBeans.makeDef(ImmutableBeans.java:146) > at > org.apache.calcite.util.ImmutableBeans.access$000(ImmutableBeans.java:55) > at > org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:68) > at > org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:65) > at > com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527) > at > com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2276) > at > com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154) > at > com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3973) > at > com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4957) > at > org.apache.calcite.util.ImmutableBeans.create_(ImmutableBeans.java:95) > at > org.apache.calcite.util.ImmutableBeans.create(ImmutableBeans.java:76) > at > org.apache.calcite.sql.validate.SqlValidator$Config.(SqlValidator.java:792) > ... 19 more > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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
[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&focusedCommentId=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"
[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&focusedCommentId=17380105#comment-17380105 ] Nikolay Izhikov commented on IGNITE-15116: -- https://ci.ignite.apache.org/viewLog.html?buildId=6085067&buildTypeId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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=6083363&buildTypeId=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&focusedCommentId=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=6084197&buildTypeId=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&focusedCommentId=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)