[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878256=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878256 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 21:47 Start Date: 24/Aug/23 21:47 Worklog Time Spent: 10m Work Description: amarkevich commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1692456421 > prefers stability in one of previous PR I made a mistake and broke artemis-log-annotation-processor. And PR check passed. This is my own expirience of using this project as developer. Feel free to keep such behaviour. > why the change should be accepted get rid of reflection is the main point Issue Time Tracking --- Worklog Id: (was: 878256) Time Spent: 4h 20m (was: 4h 10m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 4h 20m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4401) slow performance of JDBC while paging
[ https://issues.apache.org/jira/browse/ARTEMIS-4401?focusedWorklogId=878253=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878253 ] ASF GitHub Bot logged work on ARTEMIS-4401: --- Author: ASF GitHub Bot Created on: 24/Aug/23 21:16 Start Date: 24/Aug/23 21:16 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4591: URL: https://github.com/apache/activemq-artemis/pull/4591 (no comment) Issue Time Tracking --- Worklog Id: (was: 878253) Remaining Estimate: 0h Time Spent: 10m > slow performance of JDBC while paging > - > > Key: ARTEMIS-4401 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4401 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.31.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Syncs are not properly implemented into page files. Basically ever message > sent and every blob update is issuing a sync update on the context and a > commit on the Database. > Certain databases will have an OK performance with lots of commits (e.g. > Postgres) but I'm not sure how correct is the blob update. > As part of this task I'm creating a few Database tests to validate these > changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4401) slow performance of JDBC while paging
Clebert Suconic created ARTEMIS-4401: Summary: slow performance of JDBC while paging Key: ARTEMIS-4401 URL: https://issues.apache.org/jira/browse/ARTEMIS-4401 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.31.0 Syncs are not properly implemented into page files. Basically ever message sent and every blob update is issuing a sync update on the context and a commit on the Database. Certain databases will have an OK performance with lots of commits (e.g. Postgres) but I'm not sure how correct is the blob update. As part of this task I'm creating a few Database tests to validate these changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878243=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878243 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 19:11 Start Date: 24/Aug/23 19:11 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1692266650 > I listed them in jira... The bullet points you provided in the Jira and here in the PR are _not_ a use-case. They are simply a summary of what you changed. There is no real explanation of _why_ the existing code is problematic or _how_ your change benefits the project. Perhaps those things are obvious to you, but they are not obvious to me and likely not obvious to many other developers and users. > And still no any valuable cons Generally speaking, the project prefers stability and continuity as that typically mitigates risk for our users - something which is greatly valued. Therefore, anybody who is proposing a change must make an understandable case for _why_ the change should be accepted. > Aren't listed pros enough? At this point the pros you've listed are not enough. Issue Time Tracking --- Worklog Id: (was: 878243) Time Spent: 4h 10m (was: 4h) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 4h 10m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4349) Replace Guava cache with Caffeine
[ https://issues.apache.org/jira/browse/ARTEMIS-4349?focusedWorklogId=878241=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878241 ] ASF GitHub Bot logged work on ARTEMIS-4349: --- Author: ASF GitHub Bot Created on: 24/Aug/23 18:43 Start Date: 24/Aug/23 18:43 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4584: URL: https://github.com/apache/activemq-artemis/pull/4584#issuecomment-1692229955 > So I guess its just a case of deciding whether we want to retain the guava-style inline execution behaviour, or change to the Caffeine async execution default. Regarding the cache usage in `org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl` my thoughts are: 1. The only use-case where it really matters is with size = 0 and that's been fixed that already via #4589. 2. It makes sense to optimize security since it is used basically every time a client connects. Therefore, I'm in favor of using the default from Caffeine. Issue Time Tracking --- Worklog Id: (was: 878241) Time Spent: 9h 40m (was: 9.5h) > Replace Guava cache with Caffeine > - > > Key: ARTEMIS-4349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4349 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.29.0 >Reporter: Alexey Markevich >Priority: Major > Time Spent: 9h 40m > Remaining Estimate: 0h > > based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4378) Federation, ignore address policy when using pull consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-4378?focusedWorklogId=878240=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878240 ] ASF GitHub Bot logged work on ARTEMIS-4378: --- Author: ASF GitHub Bot Created on: 24/Aug/23 18:22 Start Date: 24/Aug/23 18:22 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4590: URL: https://github.com/apache/activemq-artemis/pull/4590#issuecomment-1692202993 LGTM Issue Time Tracking --- Worklog Id: (was: 878240) Time Spent: 40m (was: 0.5h) > Federation, ignore address policy when using pull consumer connection > -- > > Key: ARTEMIS-4378 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4378 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.29.0 >Reporter: Gary Tully >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Using the batching pull consumer from ARTEMIS-4314 is only applicable to > queue Federation but both policies can be configured in the same federation. > If consumer window size of zero is configured any address policy should be > ignored. With address federation there is no local queue to gauge capacity > and messages will just accumate in the upstream. The concept of a pull > consumer for address federation does not make any sense. > This strategy is already adopted for queue Federation configured for > multicast addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4349) Replace Guava cache with Caffeine
[
https://issues.apache.org/jira/browse/ARTEMIS-4349?focusedWorklogId=878238=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878238
]
ASF GitHub Bot logged work on ARTEMIS-4349:
---
Author: ASF GitHub Bot
Created on: 24/Aug/23 18:17
Start Date: 24/Aug/23 18:17
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4584:
URL: https://github.com/apache/activemq-artemis/pull/4584#discussion_r1304702894
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java:
##
@@ -101,15 +103,15 @@ public SecurityStoreImpl(final
HierarchicalRepository> securityReposit
if (authenticationCacheSize == 0) {
authenticationCache = null;
} else {
- authenticationCache = CacheBuilder.newBuilder()
+ authenticationCache = Caffeine.newBuilder()
.maximumSize(authenticationCacheSize)
.expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
.build();
}
if (authorizationCacheSize == 0) {
authorizationCache = null;
} else {
- authorizationCache = CacheBuilder.newBuilder()
+ authorizationCache = Caffeine.newBuilder()
.maximumSize(authorizationCacheSize)
.expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
.build();
Review Comment:
Same as above.
Issue Time Tracking
---
Worklog Id: (was: 878238)
Time Spent: 9.5h (was: 9h 20m)
> Replace Guava cache with Caffeine
> -
>
> Key: ARTEMIS-4349
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4349
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.29.0
>Reporter: Alexey Markevich
>Priority: Major
> Time Spent: 9.5h
> Remaining Estimate: 0h
>
> based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4349) Replace Guava cache with Caffeine
[
https://issues.apache.org/jira/browse/ARTEMIS-4349?focusedWorklogId=878237=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878237
]
ASF GitHub Bot logged work on ARTEMIS-4349:
---
Author: ASF GitHub Bot
Created on: 24/Aug/23 18:17
Start Date: 24/Aug/23 18:17
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4584:
URL: https://github.com/apache/activemq-artemis/pull/4584#discussion_r1304702494
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java:
##
@@ -101,15 +103,15 @@ public SecurityStoreImpl(final
HierarchicalRepository> securityReposit
if (authenticationCacheSize == 0) {
authenticationCache = null;
} else {
- authenticationCache = CacheBuilder.newBuilder()
+ authenticationCache = Caffeine.newBuilder()
.maximumSize(authenticationCacheSize)
.expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
.build();
Review Comment:
This is a bit of a nit-pick, but the lines should be re-aligned so all the
`.` characters are in line vertically.
Issue Time Tracking
---
Worklog Id: (was: 878237)
Time Spent: 9h 20m (was: 9h 10m)
> Replace Guava cache with Caffeine
> -
>
> Key: ARTEMIS-4349
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4349
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.29.0
>Reporter: Alexey Markevich
>Priority: Major
> Time Spent: 9h 20m
> Remaining Estimate: 0h
>
> based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4378) Federation, ignore address policy when using pull consumer connection
[
https://issues.apache.org/jira/browse/ARTEMIS-4378?focusedWorklogId=878230=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878230
]
ASF GitHub Bot logged work on ARTEMIS-4378:
---
Author: ASF GitHub Bot
Created on: 24/Aug/23 17:08
Start Date: 24/Aug/23 17:08
Worklog Time Spent: 10m
Work Description: gtully commented on code in PR #4590:
URL: https://github.com/apache/activemq-artemis/pull/4590#discussion_r1304632604
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/federation/address/FederatedAddress.java:
##
@@ -310,10 +312,15 @@ private boolean match(AddressInfo addressInfo) {
}
private boolean match(SimpleString address, RoutingType routingType) {
- //Currently only supporting Multicast currently.
+ // only supporting Multicast currently.
if (RoutingType.ANYCAST.equals(routingType)) {
return false;
}
+ if (hasPullConnectionConfig) {
+ // multicast address federation has no local queue to trigger batch
pull requests, a regular fast consumer with credit window is necessary
+ // otherwise the upstream would fill up and block.
Review Comment:
thanks Tim, sure it won't hurt and could help. Can do the same for both
config error clauses.
Issue Time Tracking
---
Worklog Id: (was: 878230)
Time Spent: 0.5h (was: 20m)
> Federation, ignore address policy when using pull consumer connection
> --
>
> Key: ARTEMIS-4378
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4378
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Federation
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Using the batching pull consumer from ARTEMIS-4314 is only applicable to
> queue Federation but both policies can be configured in the same federation.
> If consumer window size of zero is configured any address policy should be
> ignored. With address federation there is no local queue to gauge capacity
> and messages will just accumate in the upstream. The concept of a pull
> consumer for address federation does not make any sense.
> This strategy is already adopted for queue Federation configured for
> multicast addresses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878219=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878219 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 16:36 Start Date: 24/Aug/23 16:36 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1692040983 you're doing compile time validation.. sure.but that's a small gain compared to other things. as I said I would rather keep it this way. Issue Time Tracking --- Worklog Id: (was: 878219) Time Spent: 4h (was: 3h 50m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 4h > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878215=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878215 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 16:19 Start Date: 24/Aug/23 16:19 Worklog Time Spent: 10m Work Description: amarkevich commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1692016060 > than this Aren't listed pros enough? Issue Time Tracking --- Worklog Id: (was: 878215) Time Spent: 3h 50m (was: 3h 40m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 3h 50m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878204=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878204 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 15:16 Start Date: 24/Aug/23 15:16 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691877917 @amarkevich Jboss Logging used to be part of this project.. and we used it in the past.. and we want to keep the same standard in this. what's your point on this? this change is not going to happen. we can spend time into something more positive than this. Issue Time Tracking --- Worklog Id: (was: 878204) Time Spent: 3h 40m (was: 3.5h) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 3h 40m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878201=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878201 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 15:06 Start Date: 24/Aug/23 15:06 Worklog Time Spent: 10m Work Description: amarkevich commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691860956 > interface must not have knowledge its not mandatory. I see this interface like a centralized place where all log annotations collected Issue Time Tracking --- Worklog Id: (was: 878201) Time Spent: 3.5h (was: 3h 20m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 3.5h > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878200=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878200 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 15:04 Start Date: 24/Aug/23 15:04 Worklog Time Spent: 10m Work Description: amarkevich commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691857979 > you're not hiding the annotation yep - logger implementation details are hidden > Jboss Logging is not a part of this project > use a concrete implementation directly current log processor generates message prefix general way and protect log messages from being corrupted by mistake Issue Time Tracking --- Worklog Id: (was: 878200) Time Spent: 3h 20m (was: 3h 10m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 3h 20m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4349) Replace Guava cache with Caffeine
[ https://issues.apache.org/jira/browse/ARTEMIS-4349?focusedWorklogId=878199=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878199 ] ASF GitHub Bot logged work on ARTEMIS-4349: --- Author: ASF GitHub Bot Created on: 24/Aug/23 15:03 Start Date: 24/Aug/23 15:03 Worklog Time Spent: 10m Work Description: gemmellr commented on PR #4584: URL: https://github.com/apache/activemq-artemis/pull/4584#issuecomment-1691855301 > See #4589. With this PR rebased after those changes went in, I retested these changes with and without the final commit making the eviction processing behave more like Guava's. As expected, both ways now pass the previously-failing test, now that the likely underlying issue of 'temporarily caching when max size is 0' issue was resolved by the other PR omitting the cache in that situation. So I guess its just a case of deciding whether we want to retain the guava-style inline execution behaviour, or change to the Caffeine async execution default. Issue Time Tracking --- Worklog Id: (was: 878199) Time Spent: 9h 10m (was: 9h) > Replace Guava cache with Caffeine > - > > Key: ARTEMIS-4349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4349 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.29.0 >Reporter: Alexey Markevich >Priority: Major > Time Spent: 9h 10m > Remaining Estimate: 0h > > based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878197=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878197 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:54 Start Date: 24/Aug/23 14:54 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691838912 the annotation generates the implementation, and the interface must not have knowledge about the implementation, done thought the little framework. if I could instantiate directly, we would just get rid of the processor and go straight to the implementation always. Issue Time Tracking --- Worklog Id: (was: 878197) Time Spent: 3h 10m (was: 3h) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 3h 10m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878196=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878196 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:52 Start Date: 24/Aug/23 14:52 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691835891 Man, this is painting the bike shed.. you're not hiding the annotation.. Look how Jboss Logging used to work.. we don't want to diverge here. If I was up to do new LoggingImplementation. I would just get rid of the annotation and use a concrete implementation directly. and please, don't do that. Issue Time Tracking --- Worklog Id: (was: 878196) Time Spent: 3h (was: 2h 50m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 3h > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878193=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878193 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:45 Start Date: 24/Aug/23 14:45 Worklog Time Spent: 10m Work Description: amarkevich commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691824453 > _concrete use-case_ I listed them in jira: - compilation error instead of runtime exception in case of logger annotation processor issue; - get rid of java.lang.reflect.* & java.security.* usage for logger case - hide logger implementation And still no any valuable cons Issue Time Tracking --- Worklog Id: (was: 878193) Time Spent: 2h 50m (was: 2h 40m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 2h 50m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9239) Jakarta JMS package namespace for broker
[ https://issues.apache.org/jira/browse/AMQ-9239?focusedWorklogId=878191=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878191 ] ASF GitHub Bot logged work on AMQ-9239: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:42 Start Date: 24/Aug/23 14:42 Worklog Time Spent: 10m Work Description: mattrpav commented on code in PR #996: URL: https://github.com/apache/activemq/pull/996#discussion_r1304446262 ## pom.xml: ## @@ -67,16 +67,16 @@ 4.4.16 1.2.0.Beta4 2.15.2 -2.0.3 +3.1.0 Review Comment: Fixed as part of activemq-client-jakarta changes, that include adding Maven relocation info for that module. Issue Time Tracking --- Worklog Id: (was: 878191) Time Spent: 6h 20m (was: 6h 10m) > Jakarta JMS package namespace for broker > > > Key: AMQ-9239 > URL: https://issues.apache.org/jira/browse/AMQ-9239 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Time Spent: 6h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9239) Jakarta JMS package namespace for broker
[ https://issues.apache.org/jira/browse/AMQ-9239?focusedWorklogId=878190=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878190 ] ASF GitHub Bot logged work on AMQ-9239: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:41 Start Date: 24/Aug/23 14:41 Worklog Time Spent: 10m Work Description: mattrpav commented on PR #996: URL: https://github.com/apache/activemq/pull/996#issuecomment-1691816548 > > > Have you tried running a test release build with all the plugins? For example, I'm getting errors trying to build javadocs so that needs to be fixed. > > > > > > DONE: javadocs processing is fixed in latest commit: [48e4e44](https://github.com/apache/activemq/commit/48e4e448f4a140b308f113b941ea9cc218409ccc) > > > Also, we should make sure that activemq-openwire-generator works and that is apparently broken with JDK 17. See: https://lists.apache.org/thread/rfjh94otnbx8h1rxs0l7d654zbf436wn > > > > > > I think this is reasonable to separate out into a follow-on JIRA. The openwire-generator is not actively used in the release toolchain, and without an openwire version change this would not block a release. I think it should be 'short term'. (ie within first few point releases of 5.19.0). > > Thoughts? > > It could be a different Jira/Issue but I think it should probably be fixed before we do a 5.19.0 release. If we can't build a new OpenWire version then that is a problem and should be fixed because otherwise it will get ignored and then will be a huge problem later when we do need to build it. It may also be broken for 5.18.x and JDK 11 so we should look at that too and fix before another 5.18.x release. If there is a reason that we can't fix it now then it should at least be documented as to what is broken and what needs fixing. Sounds good to me. I created the JIRA w/ info from the mailing list discussion and set the Fix Version to 5.19.0. ref: https://issues.apache.org/jira/browse/AMQ-9302 Issue Time Tracking --- Worklog Id: (was: 878190) Time Spent: 6h 10m (was: 6h) > Jakarta JMS package namespace for broker > > > Key: AMQ-9239 > URL: https://issues.apache.org/jira/browse/AMQ-9239 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Time Spent: 6h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9302) Modernize activemq-openwire-generator
[ https://issues.apache.org/jira/browse/AMQ-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-9302: Description: 1. Update tooling for JDK 17 2. Update tooling to add execution targets based on language desired 3. Update documentation ref: Last commit w/ openwire change (v12) https://github.com/apache/activemq/commit/3953b9aaefaee914bdd0702f27aef47c021ceb27 was: 1. Update tooling for JDK 17 2. Update tooling to add execution targets based on language desired 3. Update documentation > Modernize activemq-openwire-generator > - > > Key: AMQ-9302 > URL: https://issues.apache.org/jira/browse/AMQ-9302 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Priority: Minor > Fix For: 5.19.0 > > > 1. Update tooling for JDK 17 > 2. Update tooling to add execution targets based on language desired > 3. Update documentation > ref: Last commit w/ openwire change (v12) > https://github.com/apache/activemq/commit/3953b9aaefaee914bdd0702f27aef47c021ceb27 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4378) Federation, ignore address policy when using pull consumer connection
[
https://issues.apache.org/jira/browse/ARTEMIS-4378?focusedWorklogId=878189=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878189
]
ASF GitHub Bot logged work on ARTEMIS-4378:
---
Author: ASF GitHub Bot
Created on: 24/Aug/23 14:40
Start Date: 24/Aug/23 14:40
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4590:
URL: https://github.com/apache/activemq-artemis/pull/4590#discussion_r1304443770
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/federation/address/FederatedAddress.java:
##
@@ -310,10 +312,15 @@ private boolean match(AddressInfo addressInfo) {
}
private boolean match(SimpleString address, RoutingType routingType) {
- //Currently only supporting Multicast currently.
+ // only supporting Multicast currently.
if (RoutingType.ANYCAST.equals(routingType)) {
return false;
}
+ if (hasPullConnectionConfig) {
+ // multicast address federation has no local queue to trigger batch
pull requests, a regular fast consumer with credit window is necessary
+ // otherwise the upstream would fill up and block.
Review Comment:
It is probably worth logging something here (debug level probably) that
indicates that a match was rejected because pull consumer was configured and
the core federation doesn't allow a way to have both address and queue
federation when in pull mode. At least then you have a breadcrumb to debug it
when someone complains their address federation is broken.
Issue Time Tracking
---
Worklog Id: (was: 878189)
Time Spent: 20m (was: 10m)
> Federation, ignore address policy when using pull consumer connection
> --
>
> Key: ARTEMIS-4378
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4378
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Federation
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Using the batching pull consumer from ARTEMIS-4314 is only applicable to
> queue Federation but both policies can be configured in the same federation.
> If consumer window size of zero is configured any address policy should be
> ignored. With address federation there is no local queue to gauge capacity
> and messages will just accumate in the upstream. The concept of a pull
> consumer for address federation does not make any sense.
> This strategy is already adopted for queue Federation configured for
> multicast addresses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9302) Modernize activemq-openwire-generator
[
https://issues.apache.org/jira/browse/AMQ-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758620#comment-17758620
]
Matt Pavlovich commented on AMQ-9302:
-
>From [~tabish] activemq dev mailing list post
{noformat}
I spent a little time just to resurrect some knowledge on this, here's the
basics
To run the generator in the ActiveMQ source tree you need to enable the profile
in the activemq-client module for the openwire generator and use the generate
sources goal:
mvn -P openwire-generate generate-sources
This will at least try and generate the sources, the profile configuration
tells it what the highest version is to generate in an ant task which needs to
be moved to an ant target now as task is deprecated and will fall on its face
until you do so. Then it will actually try and do something, so if you added
openwire v13 you'd change it or leave it at v12 and see if you can generate
matching output and run the above command at which point it will fall on its
face if you are on JDK 17 as the underlying javadoc types used by the generator
are relocated to 'jdk.javadoc.doclet' and renamed or refactored into something
close but not quite the same. So then you run it on JDK 11 and it will fall on
its face with an NPE that I didn't bother to look deeper into but at least you
have a starting point.
Likely the ancient annogen and gram stuff just won't work on a newer JDK, you
could try running it on lower versions but the maven configuration will likely
be unhappy as the compiler configuration is set to target 11 currently.
Hopefully that at least gets you pointed in the right direction, frustrating as
it may be.
{noformat}
> Modernize activemq-openwire-generator
> -
>
> Key: AMQ-9302
> URL: https://issues.apache.org/jira/browse/AMQ-9302
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0
>
>
> 1. Update tooling for JDK 17
> 2. Update tooling to add execution targets based on language desired
> 3. Update documentation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (AMQ-9302) Modernize activemq-openwire-generator
Matt Pavlovich created AMQ-9302: --- Summary: Modernize activemq-openwire-generator Key: AMQ-9302 URL: https://issues.apache.org/jira/browse/AMQ-9302 Project: ActiveMQ Issue Type: Task Reporter: Matt Pavlovich 1. Update tooling for JDK 17 2. Update tooling to add execution targets based on language desired 3. Update documentation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9302) Modernize activemq-openwire-generator
[ https://issues.apache.org/jira/browse/AMQ-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-9302: Fix Version/s: 5.19.0 > Modernize activemq-openwire-generator > - > > Key: AMQ-9302 > URL: https://issues.apache.org/jira/browse/AMQ-9302 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Priority: Minor > Fix For: 5.19.0 > > > 1. Update tooling for JDK 17 > 2. Update tooling to add execution targets based on language desired > 3. Update documentation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9239) Jakarta JMS package namespace for broker
[ https://issues.apache.org/jira/browse/AMQ-9239?focusedWorklogId=878185=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878185 ] ASF GitHub Bot logged work on AMQ-9239: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:28 Start Date: 24/Aug/23 14:28 Worklog Time Spent: 10m Work Description: cshannon commented on PR #996: URL: https://github.com/apache/activemq/pull/996#issuecomment-1691792153 > > Have you tried running a test release build with all the plugins? For example, I'm getting errors trying to build javadocs so that needs to be fixed. > > DONE: javadocs processing is fixed in latest commit: [48e4e44](https://github.com/apache/activemq/commit/48e4e448f4a140b308f113b941ea9cc218409ccc) > > > Also, we should make sure that activemq-openwire-generator works and that is apparently broken with JDK 17. See: https://lists.apache.org/thread/rfjh94otnbx8h1rxs0l7d654zbf436wn > > I think this is reasonable to separate out into a follow-on JIRA. The openwire-generator is not actively used in the release toolchain, and without an openwire version change this would not block a release. I think it should be 'short term'. (ie within first few point releases of 5.19.0). > > Thoughts? It could be a different Jira/Issue but I think it should probably be fixed before we do a 5.19.0 release. If we can't build a new OpenWire version then that is a problem and should be fixed because otherwise it will get ignored and then will be a huge problem later when we do need to build it. It may also be broken for 5.18.x and JDK 11 so we should look at that too and fix before another 5.18.x release. If there is a reason that we can't fix it now then it should at least be documented as to what is broken and what needs fixing. Issue Time Tracking --- Worklog Id: (was: 878185) Time Spent: 6h (was: 5h 50m) > Jakarta JMS package namespace for broker > > > Key: AMQ-9239 > URL: https://issues.apache.org/jira/browse/AMQ-9239 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Time Spent: 6h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9239) Jakarta JMS package namespace for broker
[ https://issues.apache.org/jira/browse/AMQ-9239?focusedWorklogId=878183=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878183 ] ASF GitHub Bot logged work on AMQ-9239: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:23 Start Date: 24/Aug/23 14:23 Worklog Time Spent: 10m Work Description: mattrpav commented on PR #996: URL: https://github.com/apache/activemq/pull/996#issuecomment-1691780360 > Have you tried running a test release build with all the plugins? For example, I'm getting errors trying to build javadocs so that needs to be fixed. DONE: javadocs processing is fixed in latest commit: 48e4e448f4a140b308f113b941ea9cc218409ccc > Also, we should make sure that activemq-openwire-generator works and that is apparently broken with JDK 17. See: https://lists.apache.org/thread/rfjh94otnbx8h1rxs0l7d654zbf436wn I think this is reasonable to separate out into a follow-on JIRA. The openwire-generator is not actively used in the release toolchain, and without an openwire version change this would not block a release. I think it should be 'short term'. (ie within first few point releases of 5.19.0). Thoughts? Issue Time Tracking --- Worklog Id: (was: 878183) Time Spent: 5h 50m (was: 5h 40m) > Jakarta JMS package namespace for broker > > > Key: AMQ-9239 > URL: https://issues.apache.org/jira/browse/AMQ-9239 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4378) Federation, ignore address policy when using pull consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-4378?focusedWorklogId=878180=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878180 ] ASF GitHub Bot logged work on ARTEMIS-4378: --- Author: ASF GitHub Bot Created on: 24/Aug/23 14:19 Start Date: 24/Aug/23 14:19 Worklog Time Spent: 10m Work Description: gtully opened a new pull request, #4590: URL: https://github.com/apache/activemq-artemis/pull/4590 …ured as pull, consumerWindowSize=0 Issue Time Tracking --- Worklog Id: (was: 878180) Remaining Estimate: 0h Time Spent: 10m > Federation, ignore address policy when using pull consumer connection > -- > > Key: ARTEMIS-4378 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4378 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.29.0 >Reporter: Gary Tully >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Using the batching pull consumer from ARTEMIS-4314 is only applicable to > queue Federation but both policies can be configured in the same federation. > If consumer window size of zero is configured any address policy should be > ignored. With address federation there is no local queue to gauge capacity > and messages will just accumate in the upstream. The concept of a pull > consumer for address federation does not make any sense. > This strategy is already adopted for queue Federation configured for > multicast addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878164=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878164 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 13:37 Start Date: 24/Aug/23 13:37 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691694000 I still don't understand the _concrete use-case_ for this change. It seems more like [bikeshedding](https://en.wiktionary.org/wiki/bikeshedding) at the moment. Issue Time Tracking --- Worklog Id: (was: 878164) Time Spent: 2h 40m (was: 2.5h) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 2h 40m > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-966) MQTT Session States do not survive a reboot
[ https://issues.apache.org/jira/browse/ARTEMIS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-966: -- Assignee: Justin Bertram > MQTT Session States do not survive a reboot > --- > > Key: ARTEMIS-966 > URL: https://issues.apache.org/jira/browse/ARTEMIS-966 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: MQTT >Reporter: Martyn Taylor >Assignee: Justin Bertram >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4399) Authentication cache set to size 0 (i.e. disabled) is not threadsafe
[
https://issues.apache.org/jira/browse/ARTEMIS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4399.
-
Fix Version/s: 2.31.0
Resolution: Fixed
> Authentication cache set to size 0 (i.e. disabled) is not threadsafe
> -
>
> Key: ARTEMIS-4399
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4399
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Rich T
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.31.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> To disable authentication cache you have to set the following config option:
> {code:java}
> setAuthenticationCacheSize(0){code}
> SecurityStoreImpl then creates the following guava cache with maximumSize set
> to 0:
> {code:java}
> authenticationCache = CacheBuilder.newBuilder()
> .maximumSize(authenticationCacheSize)
> .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
> .build();{code}
> The way the guava LocalCache implementation works with maximumSize is that
> even with size 0 an entry is added but then is removed; this means that
> another thread can end up pulling an entry out of the cache before it is
> evicted; even though maximumSize is set to 0.
> It has taken me some effort to track down this timing issue but the behaviour
> is also explained in the guava docs:
> {code:java}
> When size is zero, elements will be evicted immediately after being loaded
> into the cache. This can be useful in testing, or to disable caching
> temporarily without a code change.This feature cannot be used in conjunction
> with maximumWeight
> {code}
> Based on these findings no auth cache should be created at all when size 0 is
> requested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4399) Authentication cache set to size 0 (i.e. disabled) is not threadsafe
[
https://issues.apache.org/jira/browse/ARTEMIS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758499#comment-17758499
]
ASF subversion and git services commented on ARTEMIS-4399:
--
Commit 29fafb5fed78788851273491f6f49638cbff828b in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=29fafb5fed ]
ARTEMIS-4399 fix disabled authn/z cache
> Authentication cache set to size 0 (i.e. disabled) is not threadsafe
> -
>
> Key: ARTEMIS-4399
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4399
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Rich T
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> To disable authentication cache you have to set the following config option:
> {code:java}
> setAuthenticationCacheSize(0){code}
> SecurityStoreImpl then creates the following guava cache with maximumSize set
> to 0:
> {code:java}
> authenticationCache = CacheBuilder.newBuilder()
> .maximumSize(authenticationCacheSize)
> .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
> .build();{code}
> The way the guava LocalCache implementation works with maximumSize is that
> even with size 0 an entry is added but then is removed; this means that
> another thread can end up pulling an entry out of the cache before it is
> evicted; even though maximumSize is set to 0.
> It has taken me some effort to track down this timing issue but the behaviour
> is also explained in the guava docs:
> {code:java}
> When size is zero, elements will be evicted immediately after being loaded
> into the cache. This can be useful in testing, or to disable caching
> temporarily without a code change.This feature cannot be used in conjunction
> with maximumWeight
> {code}
> Based on these findings no auth cache should be created at all when size 0 is
> requested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4399) Authentication cache set to size 0 (i.e. disabled) is not threadsafe
[
https://issues.apache.org/jira/browse/ARTEMIS-4399?focusedWorklogId=878109=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878109
]
ASF GitHub Bot logged work on ARTEMIS-4399:
---
Author: ASF GitHub Bot
Created on: 24/Aug/23 10:25
Start Date: 24/Aug/23 10:25
Worklog Time Spent: 10m
Work Description: gemmellr merged PR #4589:
URL: https://github.com/apache/activemq-artemis/pull/4589
Issue Time Tracking
---
Worklog Id: (was: 878109)
Time Spent: 40m (was: 0.5h)
> Authentication cache set to size 0 (i.e. disabled) is not threadsafe
> -
>
> Key: ARTEMIS-4399
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4399
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Rich T
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> To disable authentication cache you have to set the following config option:
> {code:java}
> setAuthenticationCacheSize(0){code}
> SecurityStoreImpl then creates the following guava cache with maximumSize set
> to 0:
> {code:java}
> authenticationCache = CacheBuilder.newBuilder()
> .maximumSize(authenticationCacheSize)
> .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
> .build();{code}
> The way the guava LocalCache implementation works with maximumSize is that
> even with size 0 an entry is added but then is removed; this means that
> another thread can end up pulling an entry out of the cache before it is
> evicted; even though maximumSize is set to 0.
> It has taken me some effort to track down this timing issue but the behaviour
> is also explained in the guava docs:
> {code:java}
> When size is zero, elements will be evicted immediately after being loaded
> into the cache. This can be useful in testing, or to disable caching
> temporarily without a code change.This feature cannot be used in conjunction
> with maximumWeight
> {code}
> Based on these findings no auth cache should be created at all when size 0 is
> requested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4400. - Assignee: Robbie Gemmell Resolution: Fixed > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.31.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on > artemis-unit-test-support from test scope to compile scope, but it should > clearly be in test scope so swap it back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758479#comment-17758479 ] ASF subversion and git services commented on ARTEMIS-4400: -- Commit 61a8e19ecdc6e23674f22b09fcfe91a39bf25ffb in activemq-artemis's branch refs/heads/main from Alexey Markevich [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=61a8e19ecd ] ARTEMIS-4400 artemis-cdi-client: artemis-unit-test-support in test scope > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on > artemis-unit-test-support from test scope to compile scope, but it should > clearly be in test scope so swap it back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?focusedWorklogId=878102=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878102 ] ASF GitHub Bot logged work on ARTEMIS-4400: --- Author: ASF GitHub Bot Created on: 24/Aug/23 09:38 Start Date: 24/Aug/23 09:38 Worklog Time Spent: 10m Work Description: gemmellr merged PR #4588: URL: https://github.com/apache/activemq-artemis/pull/4588 Issue Time Tracking --- Worklog Id: (was: 878102) Remaining Estimate: 0h Time Spent: 10m > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on > artemis-unit-test-support from test scope to compile scope, but it should > clearly be in test scope so swap it back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Description: The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on artemis-unit-test-support from test scope to compile scope, but it should clearly be in test scope so swap it back. (was: The changes in ARTEMIS-4353 incorrectly swapped ) > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > > The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on > artemis-unit-test-support from test scope to compile scope, but it should > clearly be in test scope so swap it back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Description: The changes in ARTEMIS-4353 incorrectly swapped > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > > The changes in ARTEMIS-4353 incorrectly swapped -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Fix Version/s: 2.31.0 > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Summary: artemis-cdi-client: artemis-unit-test-support should be in test scope (was: artemis-cdi-client: artemis-unit-test-support in test scope) > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4399) Authentication cache set to size 0 (i.e. disabled) is not threadsafe
[
https://issues.apache.org/jira/browse/ARTEMIS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758425#comment-17758425
]
Rich T commented on ARTEMIS-4399:
-
Thanks for picking this up so quickly
> Authentication cache set to size 0 (i.e. disabled) is not threadsafe
> -
>
> Key: ARTEMIS-4399
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4399
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Rich T
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To disable authentication cache you have to set the following config option:
> {code:java}
> setAuthenticationCacheSize(0){code}
> SecurityStoreImpl then creates the following guava cache with maximumSize set
> to 0:
> {code:java}
> authenticationCache = CacheBuilder.newBuilder()
> .maximumSize(authenticationCacheSize)
> .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
> .build();{code}
> The way the guava LocalCache implementation works with maximumSize is that
> even with size 0 an entry is added but then is removed; this means that
> another thread can end up pulling an entry out of the cache before it is
> evicted; even though maximumSize is set to 0.
> It has taken me some effort to track down this timing issue but the behaviour
> is also explained in the guava docs:
> {code:java}
> When size is zero, elements will be evicted immediately after being loaded
> into the cache. This can be useful in testing, or to disable caching
> temporarily without a code change.This feature cannot be used in conjunction
> with maximumWeight
> {code}
> Based on these findings no auth cache should be created at all when size 0 is
> requested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4393) Explicit logger implementation instantiation
[ https://issues.apache.org/jira/browse/ARTEMIS-4393?focusedWorklogId=878071=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-878071 ] ASF GitHub Bot logged work on ARTEMIS-4393: --- Author: ASF GitHub Bot Created on: 24/Aug/23 07:48 Start Date: 24/Aug/23 07:48 Worklog Time Spent: 10m Work Description: amarkevich commented on PR #4582: URL: https://github.com/apache/activemq-artemis/pull/4582#issuecomment-1691182583 > Interfaces shouldn't have the implementation defined in there. So in case abstract class with annotations will be used instead of current interface - it can be approved? Issue Time Tracking --- Worklog Id: (was: 878071) Time Spent: 2.5h (was: 2h 20m) > Explicit logger implementation instantiation > > > Key: ARTEMIS-4393 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4393 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 2.5h > Remaining Estimate: 0h > > - compilation error instead of runtime exception in case of logger annotation > processor issue; > - get rid of java.lang.reflect.* & java.security.* usage for logger case > - hide logger implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
