Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Peter Vary]

Shall we put the core/shading to the blocker for 4.0.0?
Do we have a jira for it?

Thanks Sun Chao for bringing this up!

Peter

On Mon, May 9, 2022, 19:21 Chao Sun  wrote:

> Agree to Peter above. I know quite a few projects such as Spark,
> Iceberg and Trino/Presto are depending on Hive 2.x and 3.x, and
> periodically they may need new fixes in these. Upgrading them to use
> 4.x seems not an option for now since the core classified artifact has
> been removed and the shading issue has to be solved before they can
> consume the new jar.
>
> On Mon, May 9, 2022 at 4:10 AM Peter Vary  wrote:
> >
> > Hi Team,
> >
> > My experience with the Iceberg community shows that there are some
> sizeable userbase around Hive 2.x. I have seen patches, contributions to
> Hive 2.3.x branches, and the tests are in much better shape there.
> >
> > I would definitely vote for EOL Hive 1.x, but until we have a stable
> 4.x, I would be cautious about slashing 2.x, 3.x branches.
> >
> > Just my 2 cents.
> >
> > Peter
> >
> > On 2022. May 9., at 10:51, Alessandro Solimando <
> alessandro.solima...@gmail.com> wrote:
> >
> > Hi Stamatis,
> > thanks for bringing up this topic, I basically agree on everything you
> wrote.
> >
> > I just wanted to add that this kind of proposal might sound harsh,
> because in many contexts upgrading is a complex process, but it's in
> nobody's interest to keep release branches that are missing important
> fixes/improvements and that might not meet the quality standards that
> people expect, as mentioned.
> >
> > Since we don't have yet a stable 4.x release (only alpha for now) we
> might want to keep supporting the 3.x branch until the first 4.x stable
> release and EOL < 3.x branches, WDYT?
> >
> > Best regards,
> > Alessandro
> >
> > On Fri, 6 May 2022 at 23:14, Stamatis Zampetakis 
> wrote:
> >>
> >> Hi all,
> >>
> >> The current master has many critical bug fixes as well as important
> performance improvements that are not backported (and most likely never
> will) to the maintenance branches.
> >>
> >> Backporting changes from master usually requires adapting the code and
> tests in questions making it a non-trivial and time consuming task.
> >>
> >> The ASF bylaws require PMCs to deliver high quality software which
> satisfy certain criteria. Cutting new releases from maintenance branches
> with known critical bugs is not compliant with the ASF.
> >>
> >> CI is unstable in all maintenance branches making the quality of a
> release questionable and merging new PRs rather difficult. Enabling and
> running it frequently in all maintenance branches would require a big
> amount of resources on top of what we already need for master.
> >>
> >> History has shown that it is very difficult or impossible to properly
> maintain multiple release branches for Hive.
> >>
> >> I think it would be to the best interest of the project if the PMC
> decided to drop support for maintenance branches and focused on releasing
> exclusively from master.
> >>
> >> This mail is related to the discussion about the release cadence [1]
> since it would certainly help making Hive releases more regular. I decided
> to start a separate thread to avoid mixing multiple topics together.
> >>
> >> Looking forward to your thoughts.
> >>
> >> Best,
> >> Stamatis
> >>
> >> [1] https://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
> >>
> >
>

[jira] [Created] (HIVE-26215) Expose the MIN_HISTORY_LEVEL table through Hive sys database

[Simhadri G (Jira)]

Simhadri G created HIVE-26215:
-

 Summary:  Expose the MIN_HISTORY_LEVEL table  through Hive sys 
database 
 Key: HIVE-26215
 URL: https://issues.apache.org/jira/browse/HIVE-26215
 Project: Hive
  Issue Type: Improvement
Reporter: Simhadri G
Assignee: Simhadri G


While we still (partially) use MIN_HISTORY_LEVEL for the cleaner, we should 
expose it as a sys table so we can see what might be blocking the Cleaner 
thread.

 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Chao Sun]

Agree to Peter above. I know quite a few projects such as Spark,
Iceberg and Trino/Presto are depending on Hive 2.x and 3.x, and
periodically they may need new fixes in these. Upgrading them to use
4.x seems not an option for now since the core classified artifact has
been removed and the shading issue has to be solved before they can
consume the new jar.

On Mon, May 9, 2022 at 4:10 AM Peter Vary  wrote:
>
> Hi Team,
>
> My experience with the Iceberg community shows that there are some sizeable 
> userbase around Hive 2.x. I have seen patches, contributions to Hive 2.3.x 
> branches, and the tests are in much better shape there.
>
> I would definitely vote for EOL Hive 1.x, but until we have a stable 4.x, I 
> would be cautious about slashing 2.x, 3.x branches.
>
> Just my 2 cents.
>
> Peter
>
> On 2022. May 9., at 10:51, Alessandro Solimando 
>  wrote:
>
> Hi Stamatis,
> thanks for bringing up this topic, I basically agree on everything you wrote.
>
> I just wanted to add that this kind of proposal might sound harsh, because in 
> many contexts upgrading is a complex process, but it's in nobody's interest 
> to keep release branches that are missing important fixes/improvements and 
> that might not meet the quality standards that people expect, as mentioned.
>
> Since we don't have yet a stable 4.x release (only alpha for now) we might 
> want to keep supporting the 3.x branch until the first 4.x stable release and 
> EOL < 3.x branches, WDYT?
>
> Best regards,
> Alessandro
>
> On Fri, 6 May 2022 at 23:14, Stamatis Zampetakis  wrote:
>>
>> Hi all,
>>
>> The current master has many critical bug fixes as well as important 
>> performance improvements that are not backported (and most likely never 
>> will) to the maintenance branches.
>>
>> Backporting changes from master usually requires adapting the code and tests 
>> in questions making it a non-trivial and time consuming task.
>>
>> The ASF bylaws require PMCs to deliver high quality software which satisfy 
>> certain criteria. Cutting new releases from maintenance branches with known 
>> critical bugs is not compliant with the ASF.
>>
>> CI is unstable in all maintenance branches making the quality of a release 
>> questionable and merging new PRs rather difficult. Enabling and running it 
>> frequently in all maintenance branches would require a big amount of 
>> resources on top of what we already need for master.
>>
>> History has shown that it is very difficult or impossible to properly 
>> maintain multiple release branches for Hive.
>>
>> I think it would be to the best interest of the project if the PMC decided 
>> to drop support for maintenance branches and focused on releasing 
>> exclusively from master.
>>
>> This mail is related to the discussion about the release cadence [1] since 
>> it would certainly help making Hive releases more regular. I decided to 
>> start a separate thread to avoid mixing multiple topics together.
>>
>> Looking forward to your thoughts.
>>
>> Best,
>> Stamatis
>>
>> [1] https://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
>>
>

[jira] [Created] (HIVE-26214) Hive 3.1.3 Release Notes

[Anmol Sundaram (Jira)]

Anmol Sundaram created HIVE-26214:
-

 Summary: Hive 3.1.3 Release Notes
 Key: HIVE-26214
 URL: https://issues.apache.org/jira/browse/HIVE-26214
 Project: Hive
  Issue Type: Improvement
  Components: Documentation, Hive
Affects Versions: 3.1.3
Reporter: Anmol Sundaram


The Hive Release Notes as mentioned in 
[here|https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12346277=Html=12310843]
 does not seem to be accurate when compared with the [commit 
logs|https://github.com/apache/hive/commits/rel/release-3.1.3]. 
Can we please get this updated, if applicable ?




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (HIVE-26213) "hive.limit.pushdown.memory.usage" better not be equal to 1.0, otherwise it will raise an error

[Jingxuan Fu (Jira)]

Jingxuan Fu created HIVE-26213:
--

 Summary: "hive.limit.pushdown.memory.usage" better not be equal to 
1.0, otherwise it will raise an error
 Key: HIVE-26213
 URL: https://issues.apache.org/jira/browse/HIVE-26213
 Project: Hive
  Issue Type: Bug
Affects Versions: 3.1.2
 Environment: Hive 3.1.2
os.name=Linux
os.arch=amd64
os.version=5.4.0-72-generic
java.version=1.8.0_162
java.vendor=Oracle Corporation
Reporter: Jingxuan Fu
Assignee: Jingxuan Fu


In hive-default.xml.template

 

 

 

 
{code:java}
 hive.limit.pushdown.memory.usage 0.1 
 Expects value between 0.0f and 1.0f. The fraction of available 
memory to be used for buffering rows in Reducesink operator for limit pushdown 
optimization.  
{code}
 

 

Based on the description of hive-default.xml.template, 
hive.limit.pushdown.memory.usage expects a value between 0.0 and 1.0, setting 
hive.limit.pushdown.memory.usage to 1.0 means that it expects the available 
memory of all buffered lines for the limit pushdown optimization, and 
successfully start hiveserver2.

Then, call the java api to write a program to establish a jdbc connection as a 
client to access hive, using JDBCDemo as an example.

 
{code:java}
import demo.utils.JDBCUtils; public class JDBCDemo{ public static void 
main(String[] args) throws Exception {  JDBCUtils.init();  
JDBCUtils.createDatabase();  JDBCUtils.showDatabases();  
JDBCUtils.createTable();  JDBCUtils.showTables();  JDBCUtils.descTable();  
JDBCUtils.loadData();  JDBCUtils.selectData();  JDBCUtils.countData();  
JDBCUtils.dropDatabase();  JDBCUtils.dropTable();  JDBCUtils.destory(); } }
{code}
After running the client program, both the client and the hiveserver throw 
exceptions.

 
{code:java}
2022-05-09 19:05:36: Starting HiveServer2 SLF4J: Class path contains multiple 
SLF4J bindings. SLF4J: Found binding in 
[jar:file:/usr/local/hive/lib/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: Found binding in 
[jar:file:/usr/local/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation. SLF4J: Actual binding is of type 
[org.apache.logging.slf4j.Log4jLoggerFactory] Hive Session ID = 
67a6db8d-f957-4d5d-ac18-28403adab7f3 Hive Session ID = 
f9f8772c-5765-4c3e-bcff-ca605c667be7 OK OK OK OK OK OK OK Loading data to table 
default.emp OK FAILED: SemanticException Invalid memory usage value 1.0 for 
hive.limit.pushdown.memory.usage{code}
 

 

 
{code:java}
liky@ljq1:~/hive_jdbc_test$ ./startJDBC_0.sh  SLF4J: Class path contains 
multiple SLF4J bindings. SLF4J: Found binding in 
[jar:file:/home/liky/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.17.1/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: Found binding in 
[jar:file:/home/liky/.m2/repository/org/slf4j/slf4j-log4j12/1.7.25/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation. SLF4J: Actual binding is of type 
[org.apache.logging.slf4j.Log4jLoggerFactory] Running: drop database if exists 
hive_jdbc_test Running: create database hive_jdbc_test Running: show databases 
default hive_jdbc_test Running: drop table if exists emp Running: create table 
emp( empno int, ename string, job string, mgr int, hiredate string, sal double, 
comm double, deptno int ) row format delimited fields terminated by '\t' 
Running: show tables emp Running: desc emp empno int ename string job string 
mgr int hiredate string sal double comm double deptno int Running: load data 
local inpath '/home/liky/hiveJDBCTestData/data.txt' overwrite into table emp 
Running: select * from emp Exception in thread "main" 
org.apache.hive.service.cli.HiveSQLException: Error while compiling statement: 
FAILED: SemanticException Invalid memory usage value 1.0 for 
hive.limit.pushdown.memory.usage  at 
org.apache.hive.jdbc.Utils.verifySuccess(Utils.java:380)  at 
org.apache.hive.jdbc.Utils.verifySuccessWithInfo(Utils.java:366)  at 
org.apache.hive.jdbc.HiveStatement.runAsyncOnServer(HiveStatement.java:354)  at 
org.apache.hive.jdbc.HiveStatement.execute(HiveStatement.java:293)  at 
org.apache.hive.jdbc.HiveStatement.executeQuery(HiveStatement.java:509)  at 
demo.utils.JDBCUtils.selectData(JDBCUtils.java:98)  at 
demo.test.JDBCDemo.main(JDBCDemo.java:19){code}
 

 

Setting hive.limit.pushdown.memory.usage to 0.0 has no exception.

So, setting hive.limit.pushdown.memory.usage to 1.0 is not desirable, 
*hive-default.xml.template is not clear enough for the description of the 
boundary of the value, it is better to use the interval to indicate the value 
that is [0.0,1.0).*



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (HIVE-26212) hive fetch data timeout

[royal (Jira)]

royal created HIVE-26212:


 Summary: hive fetch data timeout
 Key: HIVE-26212
 URL: https://issues.apache.org/jira/browse/HIVE-26212
 Project: Hive
  Issue Type: Bug
  Components: HiveServer2
Affects Versions: 1.1.0
Reporter: royal






--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (HIVE-26211) "hive.server2.webui.max.historic.queries" should be avoided to be set too large, otherwise it will cause blocking

[Jingxuan Fu (Jira)]

Jingxuan Fu created HIVE-26211:
--

 Summary: "hive.server2.webui.max.historic.queries" should be 
avoided to be set too large, otherwise it will cause blocking
 Key: HIVE-26211
 URL: https://issues.apache.org/jira/browse/HIVE-26211
 Project: Hive
  Issue Type: Bug
Affects Versions: 3.1.2
 Environment: Hive 3.1.2
os.name=Linux
os.arch=amd64
os.version=5.4.0-72-generic
java.version=1.8.0_162
java.vendor=Oracle Corporation
Reporter: Jingxuan Fu
Assignee: Jingxuan Fu


In hive-default.xml.template

    hive.server2.webui.max.historic.queries
    25
    The maximum number of past queries to show in HiverSever2 
WebUI.
  
Set hive.server2.webui.max.historic.queries to a relatively large value, take 
2000 as an example, start hiveserver2, it can start hiveserver normally, 
and logging without exception.
liky@ljq1:/usr/local/hive/conf$ hiveserver2 
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/usr/local/hive/lib/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/usr/local/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
2022-05-09 20:03:41: Starting HiveServer2
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/usr/local/hive/lib/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/usr/local/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
Hive Session ID = 0b419706-4026-4a8b-80fe-b79fecbccd4f
Hive Session ID = 0f9e28d7-0081-4b2f-a743-4093c38c152d
Next, if you use beeline as a client to connect to hive and send a request for 
database related operations, for example, if you query all the databases, after 
successfully executing "show databases", beeline blocks and no other operations 
can be performed.
liky@ljq1:/opt/hive$ beeline
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/usr/local/hive/lib/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/usr/local/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
Beeline version 3.1.2 by Apache Hive
beeline> !connect jdbc:hive2://192.168.1.194:1/default
Connecting to jdbc:hive2://192.168.1.194:1/default
Enter username for jdbc:hive2://192.168.1.194:1/default: hive
Enter password for jdbc:hive2://192.168.1.194:1/default: *
Connected to: Apache Hive (version 3.1.2)
Driver: Hive JDBC (version 3.1.2)
Transaction isolation: TRANSACTION_REPEATABLE_READ
0: jdbc:hive2://192.168.1.194:1/default> show databases
. . . . . . . . . . . . . . . . . . . . . .> ;
INFO  : Compiling 
command(queryId=liky_20220509202542_15382019-f07b-40ff-840d-1f720df77d8b): show 
databases
INFO  : Concurrency mode is disabled, not creating a lock manager
INFO  : Semantic Analysis Completed (retrial = false)
INFO  : Returning Hive schema: 
Schema(fieldSchemas:[FieldSchema(name:database_name, type:string, comment:from 
deserializer)], properties:null)
INFO  : Completed compiling 
command(queryId=liky_20220509202542_15382019-f07b-40ff-840d-1f720df77d8b); Time 
taken: 0.393 seconds
INFO  : Concurrency mode is disabled, not creating a lock manager
INFO  : Executing 
command(queryId=liky_20220509202542_15382019-f07b-40ff-840d-1f720df77d8b): show 
databases
INFO  : Starting task [Stage-0:DDL] in serial mode
INFO  : Completed executing 
command(queryId=liky_20220509202542_15382019-f07b-40ff-840d-1f720df77d8b); Time 
taken: 0.109 seconds
INFO  : OK
INFO  : Concurrency mode is disabled, not creating a lock manager
++
| database_name  |
++
| default        |
++
1 row selected (1.374 seconds)
Also, on the hiveserver side, a runtime null pointer exception is thrown, and 
the observation log throws no warnings or errors.
liky@ljq1:/usr/local/hive/conf$ hiveserver2 
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/usr/local/hive/lib/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/usr/local/hadoop/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See 

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Peter Vary]

Hi Team,

My experience with the Iceberg community shows that there are some sizeable 
userbase around Hive 2.x. I have seen patches, contributions to Hive 2.3.x 
branches, and the tests are in much better shape there.

I would definitely vote for EOL Hive 1.x, but until we have a stable 4.x, I 
would be cautious about slashing 2.x, 3.x branches.

Just my 2 cents.

Peter

> On 2022. May 9., at 10:51, Alessandro Solimando 
>  wrote:
> 
> Hi Stamatis,
> thanks for bringing up this topic, I basically agree on everything you wrote. 
> 
> I just wanted to add that this kind of proposal might sound harsh, because in 
> many contexts upgrading is a complex process, but it's in nobody's interest 
> to keep release branches that are missing important fixes/improvements and 
> that might not meet the quality standards that people expect, as mentioned.
> 
> Since we don't have yet a stable 4.x release (only alpha for now) we might 
> want to keep supporting the 3.x branch until the first 4.x stable release and 
> EOL < 3.x branches, WDYT?
> 
> Best regards,
> Alessandro
> 
> On Fri, 6 May 2022 at 23:14, Stamatis Zampetakis  > wrote:
> Hi all,
> 
> The current master has many critical bug fixes as well as important 
> performance improvements that are not backported (and most likely never will) 
> to the maintenance branches.
> 
> Backporting changes from master usually requires adapting the code and tests 
> in questions making it a non-trivial and time consuming task.
> 
> The ASF bylaws require PMCs to deliver high quality software which satisfy 
> certain criteria. Cutting new releases from maintenance branches with known 
> critical bugs is not compliant with the ASF.  
> 
> CI is unstable in all maintenance branches making the quality of a release 
> questionable and merging new PRs rather difficult. Enabling and running it 
> frequently in all maintenance branches would require a big amount of 
> resources on top of what we already need for master.
> 
> History has shown that it is very difficult or impossible to properly 
> maintain multiple release branches for Hive.
> 
> I think it would be to the best interest of the project if the PMC decided to 
> drop support for maintenance branches and focused on releasing exclusively 
> from master. 
> 
> This mail is related to the discussion about the release cadence [1] since it 
> would certainly help making Hive releases more regular. I decided to start a 
> separate thread to avoid mixing multiple topics together.
> 
> Looking forward to your thoughts.   
> 
> Best,
> Stamatis
> 
> [1] https://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj 
> 
> 

Re: [DISCUSS] End of life for Hive 1.x, 2.x, 3.x

[Alessandro Solimando]

Hi Stamatis,
thanks for bringing up this topic, I basically agree on everything you
wrote.

I just wanted to add that this kind of proposal might sound harsh, because
in many contexts upgrading is a complex process, but it's in nobody's
interest to keep release branches that are missing important
fixes/improvements and that might not meet the quality standards that
people expect, as mentioned.

Since we don't have yet a stable 4.x release (only alpha for now) we might
want to keep supporting the 3.x branch until the first 4.x stable release
and EOL < 3.x branches, WDYT?

Best regards,
Alessandro

On Fri, 6 May 2022 at 23:14, Stamatis Zampetakis  wrote:

> Hi all,
>
> The current master has many critical bug fixes as well as important
> performance improvements that are not backported (and most likely never
> will) to the maintenance branches.
>
> Backporting changes from master usually requires adapting the code and
> tests in questions making it a non-trivial and time consuming task.
>
> The ASF bylaws require PMCs to deliver high quality software which satisfy
> certain criteria. Cutting new releases from maintenance branches with known
> critical bugs is not compliant with the ASF.
>
> CI is unstable in all maintenance branches making the quality of a release
> questionable and merging new PRs rather difficult. Enabling and running it
> frequently in all maintenance branches would require a big amount of
> resources on top of what we already need for master.
>
> History has shown that it is very difficult or impossible to properly
> maintain multiple release branches for Hive.
>
> I think it would be to the best interest of the project if the PMC decided
> to drop support for maintenance branches and focused on releasing
> exclusively from master.
>
> This mail is related to the discussion about the release cadence [1] since
> it would certainly help making Hive releases more regular. I decided to
> start a separate thread to avoid mixing multiple topics together.
>
> Looking forward to your thoughts.
>
> Best,
> Stamatis
>
> [1] https://lists.apache.org/thread/n245dd23kb2v3qrrfp280w3pto89khxj
>
>

[jira] [Created] (HIVE-26210) Fix tests for Cleaner failed attempt threshold

[Jira]

László Végh created HIVE-26210:
--

 Summary: Fix tests for Cleaner failed attempt threshold
 Key: HIVE-26210
 URL: https://issues.apache.org/jira/browse/HIVE-26210
 Project: Hive
  Issue Type: Bug
Reporter: László Végh






--
This message was sent by Atlassian Jira
(v8.20.7#820007)