[jira] [Updated] (AVRO-3830) Handle namespace properly if a name starts with dot
[
https://issues.apache.org/jira/browse/AVRO-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated AVRO-3830:
-
Labels: pull-request-available (was: )
> Handle namespace properly if a name starts with dot
> ---
>
> Key: AVRO-3830
> URL: https://issues.apache.org/jira/browse/AVRO-3830
> Project: Apache Avro
> Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Kousuke Saruta
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The specification says about the name and namespace like as follows.
> ??The empty string may also be used as a namespace to indicate the null
> namespace??
> ??If the name specified contains a dot, then it is assumed to be a fullname,
> and any namespace also specified is ignored??
> According to this specification, if a name in a name field starts with a dot,
> it's considered that the namespace is null and the corresponding namespace
> field should be ignored.
> For example, given the following schema.
> {code}
> {
> "name": ".record1",
> "namespace": "ns1",
> "type": "record",
> "fields": []
> }
> {code}
> The name and namespace should be "record1" and null respectively.
> But the namespace is considered as "ns1" in the current Rust binding .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-3830) Handle namespace properly if a name starts with dot
[
https://issues.apache.org/jira/browse/AVRO-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kousuke Saruta updated AVRO-3830:
-
Summary: Handle namespace properly if a name starts with dot (was: Handle
namespace property if a name starts with dot)
> Handle namespace properly if a name starts with dot
> ---
>
> Key: AVRO-3830
> URL: https://issues.apache.org/jira/browse/AVRO-3830
> Project: Apache Avro
> Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Kousuke Saruta
>Priority: Major
>
> The specification says about the name and namespace like as follows.
> ??The empty string may also be used as a namespace to indicate the null
> namespace??
> ??If the name specified contains a dot, then it is assumed to be a fullname,
> and any namespace also specified is ignored??
> According to this specification, if a name in a name field starts with a dot,
> it's considered that the namespace is null and the corresponding namespace
> field should be ignored.
> For example, given the following schema.
> {code}
> {
> "name": ".record1",
> "namespace": "ns1",
> "type": "record",
> "fields": []
> }
> {code}
> The name and namespace should be "record1" and null respectively.
> But the namespace is considered as "ns1" in the current Rust binding .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-3830) Handle namespace property if a name starts with dot
[
https://issues.apache.org/jira/browse/AVRO-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kousuke Saruta updated AVRO-3830:
-
Affects Version/s: 1.12.0
> Handle namespace property if a name starts with dot
> ---
>
> Key: AVRO-3830
> URL: https://issues.apache.org/jira/browse/AVRO-3830
> Project: Apache Avro
> Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Kousuke Saruta
>Priority: Major
>
> The specification says about the name and namespace like as follows.
> ??The empty string may also be used as a namespace to indicate the null
> namespace??
> ??If the name specified contains a dot, then it is assumed to be a fullname,
> and any namespace also specified is ignored??
> According to this specification, if a name in a name field starts with a dot,
> it's considered that the namespace is null and the corresponding namespace
> field should be ignored.
> For example, given the following schema.
> {code}
> {
> "name": ".record1",
> "namespace": "ns1",
> "type": "record",
> "fields": []
> }
> {code}
> The name and namespace should be "record1" and null respectively.
> But the namespace is considered as "ns1" in the current Rust binding .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AVRO-3829) JUnit4 to JUnit5 : continue
[ https://issues.apache.org/jira/browse/AVRO-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Le Saec reassigned AVRO-3829: > JUnit4 to JUnit5 : continue > --- > > Key: AVRO-3829 > URL: https://issues.apache.org/jira/browse/AVRO-3829 > Project: Apache Avro > Issue Type: Improvement >Reporter: Christophe Le Saec >Assignee: Christophe Le Saec >Priority: Minor > > [AVRO-3579|https://issues.apache.org/jira/browse/AVRO-3579] started to > convert JUnit4 test to JUnit5. > This JIRA is to finish the upgrade, at least for avro module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3751) FastReaderBuilder in multithread lead to infinite loop also blocking other threads
[
https://issues.apache.org/jira/browse/AVRO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753213#comment-17753213
]
Christophe Le Saec commented on AVRO-3751:
--
I made the PR to change backingStore to ConcurrentHashMap
> FastReaderBuilder in multithread lead to infinite loop also blocking other
> threads
> --
>
> Key: AVRO-3751
> URL: https://issues.apache.org/jira/browse/AVRO-3751
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Reporter: Bharat Jindal
>Assignee: Christophe Le Saec
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Java implementation we encountered a case where initiating an RecordReader
> lead to application blocking due to concurrent requests.
> I analysed thread-dumps for our application and in the very initial timeline
> of the issue - there were in total 9 threads doing some operation on
> FastReaderBuilder.
>
> Category-1 : 6 threads - Blocked on object lock as {{reap}} is a
> {{synchronised}} operation
> {noformat}
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:161)
> - waiting to lock <0x7f4f4a239ab0> (a
> org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
>
> Category-2: 2 threads - Runnable trying to insert entry into {{backingStore}}
> HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at
> java.util.HashMap$TreeNode.balanceInsertion(java.base@11.0.18/HashMap.java:2304)
> at java.util.HashMap$TreeNode.treeify(java.base@11.0.18/HashMap.java:2010)
> at java.util.HashMap$TreeNode.split(java.base@11.0.18/HashMap.java:2245)
> at java.util.HashMap.resize(java.base@11.0.18/HashMap.java:710)
> at java.util.HashMap.putVal(java.base@11.0.18/HashMap.java:659)
> at java.util.HashMap.put(java.base@11.0.18/HashMap.java:608)
> at org.apache.avro.util.WeakIdentityHashMap.put(WeakIdentityHashMap.java:122)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1004)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
>
> {noformat}
> Category-3: 1 thread - Runnable trying to remove an entry from
> {{backingStore}} HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap$TreeNode.root(java.base@11.0.18/HashMap.java:1889)
> at java.util.HashMap$TreeNode.getTreeNode(java.base@11.0.18/HashMap.java:1954)
> at java.util.HashMap.removeNode(java.base@11.0.18/HashMap.java:820)
> at java.util.HashMap.remove(java.base@11.0.18/HashMap.java:795)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:165)
> - locked <0x7f4f4a239ab0> (a org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
> Over time more and more thread started to enter in the BLOCKED state, but the
> three RUNNABLE threads remained constant.
> I think the problem is {{backingStore}} being a non concurrent HashMap (a
> relevant piece on it:
> [https://stackoverflow.com/questions/35534906/java-hashmap-getobject-infinite-loop])
> Found a similar old issue report in GenericDatumReader:
> https://issues.apache.org/jira/browse/AVRO-3531
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-3751) FastReaderBuilder in multithread lead to infinite loop also blocking other threads
[
https://issues.apache.org/jira/browse/AVRO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Le Saec updated AVRO-3751:
-
Status: Patch Available (was: Open)
> FastReaderBuilder in multithread lead to infinite loop also blocking other
> threads
> --
>
> Key: AVRO-3751
> URL: https://issues.apache.org/jira/browse/AVRO-3751
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Reporter: Bharat Jindal
>Assignee: Christophe Le Saec
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Java implementation we encountered a case where initiating an RecordReader
> lead to application blocking due to concurrent requests.
> I analysed thread-dumps for our application and in the very initial timeline
> of the issue - there were in total 9 threads doing some operation on
> FastReaderBuilder.
>
> Category-1 : 6 threads - Blocked on object lock as {{reap}} is a
> {{synchronised}} operation
> {noformat}
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:161)
> - waiting to lock <0x7f4f4a239ab0> (a
> org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
>
> Category-2: 2 threads - Runnable trying to insert entry into {{backingStore}}
> HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at
> java.util.HashMap$TreeNode.balanceInsertion(java.base@11.0.18/HashMap.java:2304)
> at java.util.HashMap$TreeNode.treeify(java.base@11.0.18/HashMap.java:2010)
> at java.util.HashMap$TreeNode.split(java.base@11.0.18/HashMap.java:2245)
> at java.util.HashMap.resize(java.base@11.0.18/HashMap.java:710)
> at java.util.HashMap.putVal(java.base@11.0.18/HashMap.java:659)
> at java.util.HashMap.put(java.base@11.0.18/HashMap.java:608)
> at org.apache.avro.util.WeakIdentityHashMap.put(WeakIdentityHashMap.java:122)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1004)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
>
> {noformat}
> Category-3: 1 thread - Runnable trying to remove an entry from
> {{backingStore}} HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap$TreeNode.root(java.base@11.0.18/HashMap.java:1889)
> at java.util.HashMap$TreeNode.getTreeNode(java.base@11.0.18/HashMap.java:1954)
> at java.util.HashMap.removeNode(java.base@11.0.18/HashMap.java:820)
> at java.util.HashMap.remove(java.base@11.0.18/HashMap.java:795)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:165)
> - locked <0x7f4f4a239ab0> (a org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
> Over time more and more thread started to enter in the BLOCKED state, but the
> three RUNNABLE threads remained constant.
> I think the problem is {{backingStore}} being a non concurrent HashMap (a
> relevant piece on it:
> [https://stackoverflow.com/questions/35534906/java-hashmap-getobject-infinite-loop])
> Found a similar old issue report in GenericDatumReader:
> https://issues.apache.org/jira/browse/AVRO-3531
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-3751) FastReaderBuilder in multithread lead to infinite loop also blocking other threads
[
https://issues.apache.org/jira/browse/AVRO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated AVRO-3751:
-
Labels: pull-request-available (was: )
> FastReaderBuilder in multithread lead to infinite loop also blocking other
> threads
> --
>
> Key: AVRO-3751
> URL: https://issues.apache.org/jira/browse/AVRO-3751
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Reporter: Bharat Jindal
>Assignee: Christophe Le Saec
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Java implementation we encountered a case where initiating an RecordReader
> lead to application blocking due to concurrent requests.
> I analysed thread-dumps for our application and in the very initial timeline
> of the issue - there were in total 9 threads doing some operation on
> FastReaderBuilder.
>
> Category-1 : 6 threads - Blocked on object lock as {{reap}} is a
> {{synchronised}} operation
> {noformat}
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:161)
> - waiting to lock <0x7f4f4a239ab0> (a
> org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
>
> Category-2: 2 threads - Runnable trying to insert entry into {{backingStore}}
> HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at
> java.util.HashMap$TreeNode.balanceInsertion(java.base@11.0.18/HashMap.java:2304)
> at java.util.HashMap$TreeNode.treeify(java.base@11.0.18/HashMap.java:2010)
> at java.util.HashMap$TreeNode.split(java.base@11.0.18/HashMap.java:2245)
> at java.util.HashMap.resize(java.base@11.0.18/HashMap.java:710)
> at java.util.HashMap.putVal(java.base@11.0.18/HashMap.java:659)
> at java.util.HashMap.put(java.base@11.0.18/HashMap.java:608)
> at org.apache.avro.util.WeakIdentityHashMap.put(WeakIdentityHashMap.java:122)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1004)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
>
> {noformat}
> Category-3: 1 thread - Runnable trying to remove an entry from
> {{backingStore}} HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap$TreeNode.root(java.base@11.0.18/HashMap.java:1889)
> at java.util.HashMap$TreeNode.getTreeNode(java.base@11.0.18/HashMap.java:1954)
> at java.util.HashMap.removeNode(java.base@11.0.18/HashMap.java:820)
> at java.util.HashMap.remove(java.base@11.0.18/HashMap.java:795)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:165)
> - locked <0x7f4f4a239ab0> (a org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
> Over time more and more thread started to enter in the BLOCKED state, but the
> three RUNNABLE threads remained constant.
> I think the problem is {{backingStore}} being a non concurrent HashMap (a
> relevant piece on it:
> [https://stackoverflow.com/questions/35534906/java-hashmap-getobject-infinite-loop])
> Found a similar old issue report in GenericDatumReader:
> https://issues.apache.org/jira/browse/AVRO-3531
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AVRO-3751) FastReaderBuilder in multithread lead to infinite loop also blocking other threads
[
https://issues.apache.org/jira/browse/AVRO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Le Saec reassigned AVRO-3751:
Assignee: Christophe Le Saec
> FastReaderBuilder in multithread lead to infinite loop also blocking other
> threads
> --
>
> Key: AVRO-3751
> URL: https://issues.apache.org/jira/browse/AVRO-3751
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Reporter: Bharat Jindal
>Assignee: Christophe Le Saec
>Priority: Major
>
> In Java implementation we encountered a case where initiating an RecordReader
> lead to application blocking due to concurrent requests.
> I analysed thread-dumps for our application and in the very initial timeline
> of the issue - there were in total 9 threads doing some operation on
> FastReaderBuilder.
>
> Category-1 : 6 threads - Blocked on object lock as {{reap}} is a
> {{synchronised}} operation
> {noformat}
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:161)
> - waiting to lock <0x7f4f4a239ab0> (a
> org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
>
> Category-2: 2 threads - Runnable trying to insert entry into {{backingStore}}
> HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at
> java.util.HashMap$TreeNode.balanceInsertion(java.base@11.0.18/HashMap.java:2304)
> at java.util.HashMap$TreeNode.treeify(java.base@11.0.18/HashMap.java:2010)
> at java.util.HashMap$TreeNode.split(java.base@11.0.18/HashMap.java:2245)
> at java.util.HashMap.resize(java.base@11.0.18/HashMap.java:710)
> at java.util.HashMap.putVal(java.base@11.0.18/HashMap.java:659)
> at java.util.HashMap.put(java.base@11.0.18/HashMap.java:608)
> at org.apache.avro.util.WeakIdentityHashMap.put(WeakIdentityHashMap.java:122)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1004)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
>
> {noformat}
> Category-3: 1 thread - Runnable trying to remove an entry from
> {{backingStore}} HashMap
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap$TreeNode.root(java.base@11.0.18/HashMap.java:1889)
> at java.util.HashMap$TreeNode.getTreeNode(java.base@11.0.18/HashMap.java:1954)
> at java.util.HashMap.removeNode(java.base@11.0.18/HashMap.java:820)
> at java.util.HashMap.remove(java.base@11.0.18/HashMap.java:795)
> at org.apache.avro.util.WeakIdentityHashMap.reap(WeakIdentityHashMap.java:165)
> - locked <0x7f4f4a239ab0> (a org.apache.avro.util.WeakIdentityHashMap)
> at org.apache.avro.util.WeakIdentityHashMap.get(WeakIdentityHashMap.java:115)
> at java.util.Map.computeIfAbsent(java.base@11.0.18/Map.java:1001)
> at
> org.apache.avro.io.FastReaderBuilder.getRecordReaderFromCache(FastReaderBuilder.java:246)
> {noformat}
> Over time more and more thread started to enter in the BLOCKED state, but the
> three RUNNABLE threads remained constant.
> I think the problem is {{backingStore}} being a non concurrent HashMap (a
> relevant piece on it:
> [https://stackoverflow.com/questions/35534906/java-hashmap-getobject-infinite-loop])
> Found a similar old issue report in GenericDatumReader:
> https://issues.apache.org/jira/browse/AVRO-3531
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3828) [Rust] Use newer Github actions for setting up Rust
[ https://issues.apache.org/jira/browse/AVRO-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3828. - Fix Version/s: 1.12.0 1.11.3 Resolution: Fixed > [Rust] Use newer Github actions for setting up Rust > --- > > Key: AVRO-3828 > URL: https://issues.apache.org/jira/browse/AVRO-3828 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Affects Versions: 1.11.2 >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0, 1.11.3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > [https://github.com/apache/avro/actions/runs/5817968858?pr=2433] produces > several types of warnings: > * The following actions uses node12 which is deprecated and will be forced > to run on node16: actions-rs/toolchain@v1, actions-rs/cargo@v1. For more > info: > [https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/] > * The `set-output` command is deprecated and will be disabled soon. Please > upgrade to using Environment Files. For more information see: > [https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/] > * some crates are on edition 2021 which defaults to `resolver = "2"`, but > virtual workspaces default to `resolver = "1"` > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3828) [Rust] Use newer Github actions for setting up Rust
[ https://issues.apache.org/jira/browse/AVRO-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753104#comment-17753104 ] ASF subversion and git services commented on AVRO-3828: --- Commit c382763d7d690e4a9f7bec4369b97d5c3d0bff19 in avro's branch refs/heads/branch-1.11 from Martin Grigorov [ https://gitbox.apache.org/repos/asf?p=avro.git;h=c382763d7 ] AVRO-3828: [Rust] Fix CI build warnings (#2434) * AVRO-3828: [Rust] Enable "RUSTFLAGS=-Dwarnings" for all Rust CI workflows Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [Rust] Replace Github Action actions-rs with dtolnay/toolchain Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [PHP] Replace usage of ::set-output with $GITHUB_OUTPUT See https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [Rust] Quote the versions of Rust in the CI matrix Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [Rust] Use dtolnay/toolchain@nightly only Only '@nightly' is whitelisted by ASF Infra Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: Remove '--manifest-path ...'. defaults: run: working-directory: lang/rust now is taken into account! Signed-off-by: Martin Tzvetanov Grigorov - Signed-off-by: Martin Tzvetanov Grigorov (cherry picked from commit e6d18045b89c56da866999ca6b208324b49184e5) > [Rust] Use newer Github actions for setting up Rust > --- > > Key: AVRO-3828 > URL: https://issues.apache.org/jira/browse/AVRO-3828 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Affects Versions: 1.11.2 >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > [https://github.com/apache/avro/actions/runs/5817968858?pr=2433] produces > several types of warnings: > * The following actions uses node12 which is deprecated and will be forced > to run on node16: actions-rs/toolchain@v1, actions-rs/cargo@v1. For more > info: > [https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/] > * The `set-output` command is deprecated and will be disabled soon. Please > upgrade to using Environment Files. For more information see: > [https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/] > * some crates are on edition 2021 which defaults to `resolver = "2"`, but > virtual workspaces default to `resolver = "1"` > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3828) [Rust] Use newer Github actions for setting up Rust
[ https://issues.apache.org/jira/browse/AVRO-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753102#comment-17753102 ] ASF subversion and git services commented on AVRO-3828: --- Commit e6d18045b89c56da866999ca6b208324b49184e5 in avro's branch refs/heads/master from Martin Grigorov [ https://gitbox.apache.org/repos/asf?p=avro.git;h=e6d18045b ] AVRO-3828: [Rust] Fix CI build warnings (#2434) * AVRO-3828: [Rust] Enable "RUSTFLAGS=-Dwarnings" for all Rust CI workflows Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [Rust] Replace Github Action actions-rs with dtolnay/toolchain Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [PHP] Replace usage of ::set-output with $GITHUB_OUTPUT See https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [Rust] Quote the versions of Rust in the CI matrix Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: [Rust] Use dtolnay/toolchain@nightly only Only '@nightly' is whitelisted by ASF Infra Signed-off-by: Martin Tzvetanov Grigorov * AVRO-3828: Remove '--manifest-path ...'. defaults: run: working-directory: lang/rust now is taken into account! Signed-off-by: Martin Tzvetanov Grigorov - Signed-off-by: Martin Tzvetanov Grigorov > [Rust] Use newer Github actions for setting up Rust > --- > > Key: AVRO-3828 > URL: https://issues.apache.org/jira/browse/AVRO-3828 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Affects Versions: 1.11.2 >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > [https://github.com/apache/avro/actions/runs/5817968858?pr=2433] produces > several types of warnings: > * The following actions uses node12 which is deprecated and will be forced > to run on node16: actions-rs/toolchain@v1, actions-rs/cargo@v1. For more > info: > [https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/] > * The `set-output` command is deprecated and will be disabled soon. Please > upgrade to using Environment Files. For more information see: > [https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/] > * some crates are on edition 2021 which defaults to `resolver = "2"`, but > virtual workspaces default to `resolver = "1"` > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3828) [Rust] Use newer Github actions for setting up Rust
[ https://issues.apache.org/jira/browse/AVRO-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753100#comment-17753100 ] ASF subversion and git services commented on AVRO-3828: --- Commit f3ba1ee120e46d8b6d0241aeffdbf7b85068600a in avro's branch refs/heads/avro-3828-fix-ci-build-warnings from Martin Tzvetanov Grigorov [ https://gitbox.apache.org/repos/asf?p=avro.git;h=f3ba1ee12 ] AVRO-3828: Remove '--manifest-path ...'. defaults: run: working-directory: lang/rust now is taken into account! Signed-off-by: Martin Tzvetanov Grigorov > [Rust] Use newer Github actions for setting up Rust > --- > > Key: AVRO-3828 > URL: https://issues.apache.org/jira/browse/AVRO-3828 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Affects Versions: 1.11.2 >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > [https://github.com/apache/avro/actions/runs/5817968858?pr=2433] produces > several types of warnings: > * The following actions uses node12 which is deprecated and will be forced > to run on node16: actions-rs/toolchain@v1, actions-rs/cargo@v1. For more > info: > [https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/] > * The `set-output` command is deprecated and will be disabled soon. Please > upgrade to using Environment Files. For more information see: > [https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/] > * some crates are on edition 2021 which defaults to `resolver = "2"`, but > virtual workspaces default to `resolver = "1"` > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3828) [Rust] Use newer Github actions for setting up Rust
[ https://issues.apache.org/jira/browse/AVRO-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753097#comment-17753097 ] ASF subversion and git services commented on AVRO-3828: --- Commit 3ff64a833d2e9b74b6d2079f7f6379a25c241ef3 in avro's branch refs/heads/avro-3828-fix-ci-build-warnings from Martin Tzvetanov Grigorov [ https://gitbox.apache.org/repos/asf?p=avro.git;h=3ff64a833 ] AVRO-3828: [Rust] Use dtolnay/toolchain@nightly only Only '@nightly' is whitelisted by ASF Infra Signed-off-by: Martin Tzvetanov Grigorov > [Rust] Use newer Github actions for setting up Rust > --- > > Key: AVRO-3828 > URL: https://issues.apache.org/jira/browse/AVRO-3828 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Affects Versions: 1.11.2 >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > [https://github.com/apache/avro/actions/runs/5817968858?pr=2433] produces > several types of warnings: > * The following actions uses node12 which is deprecated and will be forced > to run on node16: actions-rs/toolchain@v1, actions-rs/cargo@v1. For more > info: > [https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/] > * The `set-output` command is deprecated and will be disabled soon. Please > upgrade to using Environment Files. For more information see: > [https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/] > * some crates are on edition 2021 which defaults to `resolver = "2"`, but > virtual workspaces default to `resolver = "1"` > -- This message was sent by Atlassian Jira (v8.20.10#820010)
