[jira] [Created] (PHOENIX-6694) Share the query plan generated in data source reader in partition readers to avoid the unnecessary touch basing system tables and meta table in all the workers.

[Rajeshbabu Chintaguntla (Jira)]

Rajeshbabu Chintaguntla created PHOENIX-6694:


 Summary: Share the query plan generated in data source reader in 
partition readers to avoid the unnecessary touch basing system tables and meta 
table in all the workers.
 Key: PHOENIX-6694
 URL: https://issues.apache.org/jira/browse/PHOENIX-6694
 Project: Phoenix
  Issue Type: Bug
  Components: spark-connector
Reporter: Rajeshbabu Chintaguntla
Assignee: Rajeshbabu Chintaguntla


Currently we are preparing the query plan in both data source and partition 
readers which is creating new connection in each worker and job initialisation  
which unnecessarily  touch basing all both system catalog table, system stats 
table as well as meta. When there are jobs with millions of parallel workers 
hotspot the region servers holding the meta and system catalog as well system 
stats table. So if we share the same query plan between the workers which can 
avoid the hotspot.



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

Re: [DISCUSS] Switching Phoenix to log4j2

[Istvan Toth]

Another issue that came to my mind is the phoenix-client jar.
We're currently shading log4j1 (actually reload4j) into the JAR.

Our options are (in the order of my preference):
* drop phoenix-client (and make users migrate to phoenix-client-embedded)
* switch phoenix-client to log4j2
* we could also keep shading reload4j into it, but that would defeat the
purpose of switching backends.

If we change the logging backend in phoenix-client, we're already changing
the dependent application's logging environment,
so users may as well  switch to phoenix-client-embedded, and take control
of their backend.

Istvan

On Mon, Apr 25, 2022 at 6:47 PM Istvan Toth  wrote:

> Thanks, Geoffrey.
>
> I actually plan to push the logger changes in a separate JIRA/Commit.
> Seems like the Hbase 2.5 artifacts don't actually depend on any logging
> backend (which is nice),
> so the current log4j1 backend works fine with minimal (test only) pom
> changes.
>
>
>
> On Mon, Apr 25, 2022 at 5:50 PM Geoffrey Jacoby 
> wrote:
>
>> It's a tough question because my instinct is to run whatever logging
>> system
>> HBase uses, and that's reload4j in 2.4 and log4j2 in HBase 2.5.
>>
>> But trying to have it both ways with complicated profile magic seems like
>> it would add a lot of complexity, likely more than it's worth.
>>
>> Since log4j2 is the "future-proof" option that HBase is going to support
>> not just in 2.5 but in any future 2.6 or 3.0 going forward, I'm +1 for
>> moving to log4j2 as part of adding HBase 2.5 support.
>>
>> Geoffrey
>>
>> On Mon, Apr 25, 2022 at 4:14 AM Istvan Toth  wrote:
>>
>> > Hi!
>> >
>> > We've had a discussion
>> > 
>> on
>> > the replacement of log4j a few months ago.
>> > There were not a lot of replies, but based on Andrew's suggestion we've
>> > switched Phoenix over to reload4j as a short-term fix (as that doesn't
>> > require any changes by users).
>> >
>> > However, we want to support the upcoming HBase 2.5 in Phoenix 5.2
>> > (PHOENIX-6692), and the log4j changes have recently been backported to
>> > branch-2.5, meaning that HBase 2.5 no longer uses log4j1 at all.
>> >
>> > This adds some urgency to choosing a "final" solution in Phoenix.
>> >
>> > Being built on top of HBase, I propose that we simply follow HBase's
>> lead,
>> > and go with log4j2, as not having to work with two logging backends is
>> the
>> > easiest both for us as developers and for our users.
>> >
>> > Looking at the HBase changes, Hbase pulls in
>> > org.apache.logging.log4j:log4j-1.2-api , which means log4j2 can also
>> handle
>> > any log4j using components (hadoop, zookeeper), and a single log4j2
>> config
>> > file should be enough for the whole stack.
>> >
>> > The changes would look like something like this:
>> >
>> > - Explicitly exclude the log4j (and sl4j-logj12) libraries from all
>> > dependencies
>> > - Explicitily add the same log4j2 dependencies as HBase to phoenix-core
>> > (and remove reload4j)
>> > - Replace the log4j config file in the assembly and tests with a log4j2
>> > config file
>> > - Modify the startup scripts.
>> > - Add the logging libraries to the assemblies (and remove reload4j)
>> >
>> > This needs to be done in Omid, the queryserver, and perhaps in the
>> > connector repos as well.
>> >
>> > WDYT ?
>> >
>> > Istvan
>> >
>>
>
>
> --
> *István Tóth* | Staff Software Engineer
> st...@cloudera.com 
> [image: Cloudera] 
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image:
> Cloudera on LinkedIn] 
> 
> --
>

Re: [DISCUSS] How to handle dependabot changes

[Geoffrey Jacoby]

I'd go with option 3 (including the JIRA number in the title of the
dependabot PR) if it's possible, or option 2 (as you've done with your Omid
example) otherwise.

Geoffrey

On Mon, Apr 25, 2022 at 3:42 AM Istvan Toth  wrote:

> The recently enabled depandabot has opened a few PRs, that we should handle
> somehow.
>
> Some of those PRs, like the Hadoop versions changes are obviously
> non-starters, as they would break the project, or at the very least
> our test infra.
>
> However, some of them are relevant, and risk-free.
>
> Our current policy is that every commit should have a corresponding JIRA,
> obviously the github bot doesn' create JIRAs.
>
> We could
> - Ignore the Github PR, and just open a separate JIRA with a patch for the
> update
> - Open a JIRA, clone the GitHub PR, and change the description to include
> the JIRA
> - Something else, like modifying the dependabot PR directly to add the JIRA
> (not sure how/if that would work).
> - Skip the JIRA, and just directly commit the dependabot PR (would cause
> problems with the Release notes, and our pre-release checklists)
>
> I have opened OMID-211 according to the 2nd option here:
> https://issues.apache.org/jira/browse/OMID-221
>
> What do you think ?
>
> Istvan
>

Re: [DISCUSS] Switching Phoenix to log4j2

[Istvan Toth]

Thanks, Geoffrey.

I actually plan to push the logger changes in a separate JIRA/Commit.
Seems like the Hbase 2.5 artifacts don't actually depend on any logging
backend (which is nice),
so the current log4j1 backend works fine with minimal (test only) pom
changes.



On Mon, Apr 25, 2022 at 5:50 PM Geoffrey Jacoby  wrote:

> It's a tough question because my instinct is to run whatever logging system
> HBase uses, and that's reload4j in 2.4 and log4j2 in HBase 2.5.
>
> But trying to have it both ways with complicated profile magic seems like
> it would add a lot of complexity, likely more than it's worth.
>
> Since log4j2 is the "future-proof" option that HBase is going to support
> not just in 2.5 but in any future 2.6 or 3.0 going forward, I'm +1 for
> moving to log4j2 as part of adding HBase 2.5 support.
>
> Geoffrey
>
> On Mon, Apr 25, 2022 at 4:14 AM Istvan Toth  wrote:
>
> > Hi!
> >
> > We've had a discussion
> > 
> on
> > the replacement of log4j a few months ago.
> > There were not a lot of replies, but based on Andrew's suggestion we've
> > switched Phoenix over to reload4j as a short-term fix (as that doesn't
> > require any changes by users).
> >
> > However, we want to support the upcoming HBase 2.5 in Phoenix 5.2
> > (PHOENIX-6692), and the log4j changes have recently been backported to
> > branch-2.5, meaning that HBase 2.5 no longer uses log4j1 at all.
> >
> > This adds some urgency to choosing a "final" solution in Phoenix.
> >
> > Being built on top of HBase, I propose that we simply follow HBase's
> lead,
> > and go with log4j2, as not having to work with two logging backends is
> the
> > easiest both for us as developers and for our users.
> >
> > Looking at the HBase changes, Hbase pulls in
> > org.apache.logging.log4j:log4j-1.2-api , which means log4j2 can also
> handle
> > any log4j using components (hadoop, zookeeper), and a single log4j2
> config
> > file should be enough for the whole stack.
> >
> > The changes would look like something like this:
> >
> > - Explicitly exclude the log4j (and sl4j-logj12) libraries from all
> > dependencies
> > - Explicitily add the same log4j2 dependencies as HBase to phoenix-core
> > (and remove reload4j)
> > - Replace the log4j config file in the assembly and tests with a log4j2
> > config file
> > - Modify the startup scripts.
> > - Add the logging libraries to the assemblies (and remove reload4j)
> >
> > This needs to be done in Omid, the queryserver, and perhaps in the
> > connector repos as well.
> >
> > WDYT ?
> >
> > Istvan
> >
>


-- 
*István Tóth* | Staff Software Engineer
st...@cloudera.com 
[image: Cloudera] 
[image: Cloudera on Twitter]  [image:
Cloudera on Facebook]  [image: Cloudera
on LinkedIn] 

--

[jira] [Commented] (OMID-221) Bump junit from 4.13 to 4.13.1

[Istvan Toth (Jira)]

[ 
https://issues.apache.org/jira/browse/OMID-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527614#comment-17527614
 ] 

Istvan Toth commented on OMID-221:
--

Committed.
Thanks for the review [~gjacoby].

> Bump junit from 4.13 to 4.13.1
> --
>
> Key: OMID-221
> URL: https://issues.apache.org/jira/browse/OMID-221
> Project: Phoenix Omid
>  Issue Type: Improvement
>Affects Versions: 1.0.2
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Fix For: 1.0.3
>
>
> Tracking Jira for the GitHub dependabot PR



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

[jira] [Resolved] (OMID-221) Bump junit from 4.13 to 4.13.1

[Istvan Toth (Jira)]

 [ 
https://issues.apache.org/jira/browse/OMID-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth resolved OMID-221.
--
Fix Version/s: 1.0.3
   Resolution: Fixed

> Bump junit from 4.13 to 4.13.1
> --
>
> Key: OMID-221
> URL: https://issues.apache.org/jira/browse/OMID-221
> Project: Phoenix Omid
>  Issue Type: Improvement
>Affects Versions: 1.0.2
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
> Fix For: 1.0.3
>
>
> Tracking Jira for the GitHub dependabot PR



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

[GitHub] [phoenix-omid] stoty closed pull request #103: Bump junit from 4.13 to 4.13.1

[GitBox]

stoty closed pull request #103: Bump junit from 4.13 to 4.13.1
URL: https://github.com/apache/phoenix-omid/pull/103


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [phoenix-omid] dependabot[bot] commented on pull request #103: Bump junit from 4.13 to 4.13.1

[GitBox]

dependabot[bot] commented on PR #103:
URL: https://github.com/apache/phoenix-omid/pull/103#issuecomment-1108790486

   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. If you'd rather skip all updates until the next 
major or minor version, let me know by commenting `@dependabot ignore this 
major version` or `@dependabot ignore this minor version`.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [phoenix-omid] stoty commented on pull request #103: Bump junit from 4.13 to 4.13.1

[GitBox]

stoty commented on PR #103:
URL: https://github.com/apache/phoenix-omid/pull/103#issuecomment-1108790443

   Merged from a cloned commit.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [phoenix-omid] stoty closed pull request #104: OMID-221 Bump junit from 4.13 to 4.13.1

[GitBox]

stoty closed pull request #104: OMID-221 Bump junit from 4.13 to 4.13.1
URL: https://github.com/apache/phoenix-omid/pull/104


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] Switching Phoenix to log4j2

[Geoffrey Jacoby]

It's a tough question because my instinct is to run whatever logging system
HBase uses, and that's reload4j in 2.4 and log4j2 in HBase 2.5.

But trying to have it both ways with complicated profile magic seems like
it would add a lot of complexity, likely more than it's worth.

Since log4j2 is the "future-proof" option that HBase is going to support
not just in 2.5 but in any future 2.6 or 3.0 going forward, I'm +1 for
moving to log4j2 as part of adding HBase 2.5 support.

Geoffrey

On Mon, Apr 25, 2022 at 4:14 AM Istvan Toth  wrote:

> Hi!
>
> We've had a discussion
>  on
> the replacement of log4j a few months ago.
> There were not a lot of replies, but based on Andrew's suggestion we've
> switched Phoenix over to reload4j as a short-term fix (as that doesn't
> require any changes by users).
>
> However, we want to support the upcoming HBase 2.5 in Phoenix 5.2
> (PHOENIX-6692), and the log4j changes have recently been backported to
> branch-2.5, meaning that HBase 2.5 no longer uses log4j1 at all.
>
> This adds some urgency to choosing a "final" solution in Phoenix.
>
> Being built on top of HBase, I propose that we simply follow HBase's lead,
> and go with log4j2, as not having to work with two logging backends is the
> easiest both for us as developers and for our users.
>
> Looking at the HBase changes, Hbase pulls in
> org.apache.logging.log4j:log4j-1.2-api , which means log4j2 can also handle
> any log4j using components (hadoop, zookeeper), and a single log4j2 config
> file should be enough for the whole stack.
>
> The changes would look like something like this:
>
> - Explicitly exclude the log4j (and sl4j-logj12) libraries from all
> dependencies
> - Explicitily add the same log4j2 dependencies as HBase to phoenix-core
> (and remove reload4j)
> - Replace the log4j config file in the assembly and tests with a log4j2
> config file
> - Modify the startup scripts.
> - Add the logging libraries to the assemblies (and remove reload4j)
>
> This needs to be done in Omid, the queryserver, and perhaps in the
> connector repos as well.
>
> WDYT ?
>
> Istvan
>

[jira] [Updated] (PHOENIX-6692) Add HBase 2.5 support

[Istvan Toth (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth updated PHOENIX-6692:
-
Component/s: core

> Add HBase 2.5 support
> -
>
> Key: PHOENIX-6692
> URL: https://issues.apache.org/jira/browse/PHOENIX-6692
> Project: Phoenix
>  Issue Type: New Feature
>  Components: core
>Reporter: Geoffrey Jacoby
>Assignee: Istvan Toth
>Priority: Major
> Fix For: 5.2.0
>
>
> I was talking with [~apurtell], who's RM for HBase 2.5, and he let me know 
> that HBase 2.5 will be released very soon. Since we're also planning on 
> releasing Phoenix 5.2 soon, we should make it sure it releases with HBase 2.5 
> support assuming this isn't too time-consuming / complicated. 



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

[jira] [Assigned] (PHOENIX-6692) Add HBase 2.5 support

[Istvan Toth (Jira)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth reassigned PHOENIX-6692:


Assignee: Istvan Toth

> Add HBase 2.5 support
> -
>
> Key: PHOENIX-6692
> URL: https://issues.apache.org/jira/browse/PHOENIX-6692
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Geoffrey Jacoby
>Assignee: Istvan Toth
>Priority: Major
> Fix For: 5.2.0
>
>
> I was talking with [~apurtell], who's RM for HBase 2.5, and he let me know 
> that HBase 2.5 will be released very soon. Since we're also planning on 
> releasing Phoenix 5.2 soon, we should make it sure it releases with HBase 2.5 
> support assuming this isn't too time-consuming / complicated. 



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

[jira] [Created] (PHOENIX-6693) Remove Hbase 2.1 and Hbase 2.2 support from Phoenix

[Istvan Toth (Jira)]

Istvan Toth created PHOENIX-6693:


 Summary: Remove Hbase 2.1 and Hbase 2.2 support from Phoenix
 Key: PHOENIX-6693
 URL: https://issues.apache.org/jira/browse/PHOENIX-6693
 Project: Phoenix
  Issue Type: Task
  Components: core
Affects Versions: 5.2.0
Reporter: Istvan Toth
Assignee: Istvan Toth


Both 5.1 and 5.2 have been EOL for more than a year.

To simplify the code base, drop support for these branches before the  Phoenix 
5.2 release.



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

[DISCUSS] Switching Phoenix to log4j2

[Istvan Toth]

Hi!

We've had a discussion
 on
the replacement of log4j a few months ago.
There were not a lot of replies, but based on Andrew's suggestion we've
switched Phoenix over to reload4j as a short-term fix (as that doesn't
require any changes by users).

However, we want to support the upcoming HBase 2.5 in Phoenix 5.2
(PHOENIX-6692), and the log4j changes have recently been backported to
branch-2.5, meaning that HBase 2.5 no longer uses log4j1 at all.

This adds some urgency to choosing a "final" solution in Phoenix.

Being built on top of HBase, I propose that we simply follow HBase's lead,
and go with log4j2, as not having to work with two logging backends is the
easiest both for us as developers and for our users.

Looking at the HBase changes, Hbase pulls in
org.apache.logging.log4j:log4j-1.2-api , which means log4j2 can also handle
any log4j using components (hadoop, zookeeper), and a single log4j2 config
file should be enough for the whole stack.

The changes would look like something like this:

- Explicitly exclude the log4j (and sl4j-logj12) libraries from all
dependencies
- Explicitily add the same log4j2 dependencies as HBase to phoenix-core
(and remove reload4j)
- Replace the log4j config file in the assembly and tests with a log4j2
config file
- Modify the startup scripts.
- Add the logging libraries to the assemblies (and remove reload4j)

This needs to be done in Omid, the queryserver, and perhaps in the
connector repos as well.

WDYT ?

Istvan

[DISCUSS] How to handle dependabot changes

[Istvan Toth]

The recently enabled depandabot has opened a few PRs, that we should handle
somehow.

Some of those PRs, like the Hadoop versions changes are obviously
non-starters, as they would break the project, or at the very least
our test infra.

However, some of them are relevant, and risk-free.

Our current policy is that every commit should have a corresponding JIRA,
obviously the github bot doesn' create JIRAs.

We could
- Ignore the Github PR, and just open a separate JIRA with a patch for the
update
- Open a JIRA, clone the GitHub PR, and change the description to include
the JIRA
- Something else, like modifying the dependabot PR directly to add the JIRA
(not sure how/if that would work).
- Skip the JIRA, and just directly commit the dependabot PR (would cause
problems with the Release notes, and our pre-release checklists)

I have opened OMID-211 according to the 2nd option here:
https://issues.apache.org/jira/browse/OMID-221

What do you think ?

Istvan

[GitHub] [phoenix-omid] stoty opened a new pull request, #104: OMID-221 Bump junit from 4.13 to 4.13.1

[GitBox]

stoty opened a new pull request, #104:
URL: https://github.com/apache/phoenix-omid/pull/104

   Bumps [junit](https://github.com/junit-team/junit4) from 4.13 to 4.13.1.
   - [Release notes](https://github.com/junit-team/junit4/releases)
   - 
[Changelog](https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.1.md)
   - [Commits](https://github.com/junit-team/junit4/compare/r4.13...r4.13.1)
   
   ---
   updated-dependencies:
   - dependency-name: junit:junit
 dependency-type: direct:production
   ...
   
   Signed-off-by: dependabot[bot] 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (OMID-221) Bump junit from 4.13 to 4.13.1

[Istvan Toth (Jira)]

[ 
https://issues.apache.org/jira/browse/OMID-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527357#comment-17527357
 ] 

Istvan Toth commented on OMID-221:
--

Bumps [junit](https://github.com/junit-team/junit4) from 4.13 to 4.13.1.

Release notes
Sourced from https://github.com/junit-team/junit4/releases";>junit's 
releases.

JUnit 4.13.1
Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.1.md";>release
 notes for details.



Changelog
Sourced from https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.1.md";>junit's
 changelog.

Summary of changes in version 4.13.1
Rules
Security fix: TemporaryFolder now limits access to temporary 
folders on Java 1.7 or later
A local information disclosure vulnerability in TemporaryFolder 
has been fixed. See the published https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp";>security
 advisory for details.
Test Runners
[Pull request https://github-redirect.dependabot.com/junit-team/junit4/issues/1669";>#1669:](https://github-redirect.dependabot.com/junit-team/junit/pull/1669";>junit-team/junit#1669)
 Make FrameworkField constructor public
Prior to this change, custom runners could make FrameworkMethod 
instances, but not FrameworkField instances. This small change 
allows for both now, because FrameworkField's constructor has been 
promoted from package-private to public.



Commits

https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66";>1b683f4
 [maven-release-plugin] prepare release r4.13.1
https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2";>ce6ce3a
 Draft 4.13.1 release notes
https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24";>c29dd82
 Change version to 4.13.1-SNAPSHOT
https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567";>1d17486
 Add a link to assertThrows in exception testing
https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9";>543905d
 Use separate line for annotation in Javadoc
https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944";>510e906
 Add sub headlines to class Javadoc
https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae";>610155b
 Merge pull request from GHSA-269g-pwp5-87pp
https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec";>b6cfd1e
 Explicitly wrap float parameter for consistency (https://github-redirect.dependabot.com/junit-team/junit4/issues/1671";>#1671)
https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646";>a5d205c
 Fix GitHub link in FAQ (https://github-redirect.dependabot.com/junit-team/junit4/issues/1672";>#1672)
https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8";>3a5c6b4
 Deprecated since jdk9 replacing constructor instance of Double and Float (https://github-redirect.dependabot.com/junit-team/junit4/issues/1660";>#1660)
Additional commits viewable in https://github.com/junit-team/junit4/compare/r4.13...r4.13.1";>compare 
view





[![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=junit:junit&package-manager=maven&previous-version=4.13&new-version=4.13.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter 
it yourself. You can also trigger a rebase manually by commenting `@dependabot 
rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---


Dependabot commands and options


You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have 
been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block 
automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You 
can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot 
creating any more for this dependency (unless you reopen the PR or upgrade to 

[jira] [Created] (OMID-221) Bump junit from 4.13 to 4.13.1

[Istvan Toth (Jira)]

Istvan Toth created OMID-221:


 Summary: Bump junit from 4.13 to 4.13.1
 Key: OMID-221
 URL: https://issues.apache.org/jira/browse/OMID-221
 Project: Phoenix Omid
  Issue Type: Improvement
Affects Versions: 1.0.2
Reporter: Istvan Toth
Assignee: Istvan Toth


Tracking Jira for the GitHub dependabot PR



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