[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548984=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548984 ] ASF GitHub Bot logged work on ARTEMIS-33: - Author: ASF GitHub Bot Created on: 06/Feb/21 06:16 Start Date: 06/Feb/21 06:16 Worklog Time Spent: 10m Work Description: laeubi commented on pull request #3432: URL: https://github.com/apache/activemq-artemis/pull/3432#issuecomment-774408418 @gemmellr @gtully I think this can be used as a first step, just one thing I noticed (but that could be changed later also): Even though I removed the storage of multiple providers for the same scheme it might still be valuable to restore this. I noticed that e.g. the java sasl API do it the way that they (in case of multiple ones) ask them in order and return the first one returning a non-null client/server object. We could do a similar thing here, MechanismFinder#getFactory would then simply return a list of factories. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548984) Time Spent: 2h 40m (was: 2.5h) > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Clebert Suconic >Priority: Critical > Fix For: unscheduled > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3045) ReplicationManager can batch sent replicated packets
[ https://issues.apache.org/jira/browse/ARTEMIS-3045?focusedWorklogId=548981=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548981 ] ASF GitHub Bot logged work on ARTEMIS-3045: --- Author: ASF GitHub Bot Created on: 06/Feb/21 05:46 Start Date: 06/Feb/21 05:46 Worklog Time Spent: 10m Work Description: franz1981 edited a comment on pull request #3392: URL: https://github.com/apache/activemq-artemis/pull/3392#issuecomment-774405162 @clebertsuconic @michaelandrepearce @jbertram @brusdev @gtully This change seems to perform best, but I cannot say I am satisfied, because I see a problem both on this and the original implementation ie we are not handling back-pressure back to the replicated journal and beyond. This remind me of https://cassandra.apache.org/blog/2020/09/03/improving-resiliency.html for who is interested.. TLDR: - in the master implementation we can make the broker to go OOM by adding too many Runnables to the replication stream because it can block awaiting Netty writability for 30 seconds and stop consuming the tasks - in this PR first implementation we can have a JCTools q of the outstanding packet requests that can grow unbounded for the same reason and makes the broker to go OOM again - in this PR last implementation we can have the Netty internal outbound (off-heap) buffer that can grow unbounded Despite the first 2 solutions seems better at first look, because they wait for enough room in Netty buffer, we can still get OOM under the same circumstances ie while awaiting the backup to catch-up. We should: - track the amount of pending work for monitoring - try to propagate back-pressure until clients But given that Artemis clients are of very different types, probably we should (similar to Cassandra) setAutoread false to client connections, but that means that we rely on client to save themselves from OOM. Or, depending by client type, we can stop sending credits back to clients to slow'em. At worst we should stop accepting connecting clients too (but is too drastic, because maybe they won't make the broker to replicate anything). I cannot say what's the best option here and if we already use some form of end-to-end protection I cannot see here, but it doesn't seem the case, given that many parallel client can still cause overloading much before receiving back notification of a durable local write + backup notification. Any thought? IMO solving this correctly can bring a huge performance increase with an improved stability too. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548981) Time Spent: 4h 40m (was: 4.5h) > ReplicationManager can batch sent replicated packets > > > Key: ARTEMIS-3045 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3045 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3045) ReplicationManager can batch sent replicated packets
[ https://issues.apache.org/jira/browse/ARTEMIS-3045?focusedWorklogId=548980=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548980 ] ASF GitHub Bot logged work on ARTEMIS-3045: --- Author: ASF GitHub Bot Created on: 06/Feb/21 05:46 Start Date: 06/Feb/21 05:46 Worklog Time Spent: 10m Work Description: franz1981 edited a comment on pull request #3392: URL: https://github.com/apache/activemq-artemis/pull/3392#issuecomment-774405162 @clebertsuconic @michaelandrepearce @jbertram @brusdev @gtully This change seems to perform best, but I cannot say I am satisfied, because I see a problem both on this and the original implementation ie we are not handling back-pressure back to the replicated journal and beyond. This remind me of https://cassandra.apache.org/blog/2020/09/03/improving-resiliency.html for who is interested.. TLDR: - in the master implementation we can make the broker to go OOM by adding too many Runnables to the replication stream because it can block awaiting Netty writability for 30 seconds and stop consuming the tasks - in this PR first implementation we can have a JCTools q of the outstanding packet requests that can grow unbounded for the same reason and makes the broker to go OOM again - in this PR last implementation we can have the Netty internal outbound (off-heap) buffer thet can grow unbounded Despite the first 2 solutions seems better at first look, because they wait for enough room in Netty buffer, we can still get OOM under the same circumstances ie while awaiting the backup to catch-up. We should: - track the amount of pending work for monitoring - try to propagate back-pressure until clients But given that Artemis clients are of very different types, probably we should (similar to Cassandra) setAutoread false to client connections, but that means that we rely on client to save themselves from OOM. Or, depending by client type, we can stop sending credits back to clients to slow'em. At worst we should stop accepting connecting clients too (but is too drastic, because maybe they won't make the broker to replicate anything). I cannot say what's the best option here and if we already use some form of end-to-end protection I cannot see here, but it doesn't seem the case, given that many parallel client can still cause overloading much before receiving back notification of a durable local write + backup notification. Any thought? IMO solving this correctly can bring a huge performance increase with an improved stability too. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548980) Time Spent: 4.5h (was: 4h 20m) > ReplicationManager can batch sent replicated packets > > > Key: ARTEMIS-3045 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3045 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3045) ReplicationManager can batch sent replicated packets
[ https://issues.apache.org/jira/browse/ARTEMIS-3045?focusedWorklogId=548979=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548979 ] ASF GitHub Bot logged work on ARTEMIS-3045: --- Author: ASF GitHub Bot Created on: 06/Feb/21 05:44 Start Date: 06/Feb/21 05:44 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3392: URL: https://github.com/apache/activemq-artemis/pull/3392#issuecomment-774405162 @clebertsuconic @michaelandrepearce @jbertram @brusdev This change seems to perform best, but I cannot say I am satisfied, because I see a problem both on this and the original implementation ie we are not handling back-pressure back to the replicated journal and beyond. This remind me of https://cassandra.apache.org/blog/2020/09/03/improving-resiliency.html for who is interested.. TLDR: - in the master implementation we can make the broker to go OOM by adding too many Runnables to the replication stream because it can block awaiting Netty writability for 30 seconds and stop consuming the tasks - in this PR first implementation we can have a JCTools q of the outstanding packet requests that can grow unbounded for the same reason and makes the broker to go OOM again - in this PR last implementation we can have the Netty internal outbound (off-heap) buffer thet can grow unbounded Despite the first 2 solutions seems better at first look, because they wait for enough room in Netty buffer, we can still get OOM under the same circumstances ie while awaiting the backup to catch-up. We should: - track the amount of pending work for monitoring - try to propagate back-pressure until clients But given that Artemis clients are of very different types, probably we should (similar to Cassandra) setAutoread false to client connections, but that means that we rely on client to save themselves from OOM. Or, depending by client type, we can stop sending credits back to clients to slow'em. At worst we should stop accepting connecting clients too (but is too drastic, because maybe they won't make the broker to replicate anything). I cannot say what's the best option here and if we already use some form of end-to-end protection I cannot see here, but it doesn't seem the case, given that many parallel client can still cause overloading much before receiving back notification of a durable local write + backup notification. Any thought? IMO solving this correctly can bring a huge performance increase with an improved stability too. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548979) Time Spent: 4h 20m (was: 4h 10m) > ReplicationManager can batch sent replicated packets > > > Key: ARTEMIS-3045 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3045 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3095) add some spacing between checkboxes for Broker Diagram
[ https://issues.apache.org/jira/browse/ARTEMIS-3095?focusedWorklogId=548972=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548972 ] ASF GitHub Bot logged work on ARTEMIS-3095: --- Author: ASF GitHub Bot Created on: 06/Feb/21 04:37 Start Date: 06/Feb/21 04:37 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request #3434: URL: https://github.com/apache/activemq-artemis/pull/3434 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548972) Remaining Estimate: 0h Time Spent: 10m > add some spacing between checkboxes for Broker Diagram > -- > > Key: ARTEMIS-3095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3095 > Project: ActiveMQ Artemis > Issue Type: Wish >Affects Versions: 2.16.0 >Reporter: Erwin Dondorp >Priority: Minor > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 10m > Remaining Estimate: 0h > > The "Broker Diagram" page shows 5 checkboxes on one row. Because these are > tightly packed, it is unclear which checkbox belongs to which label. When > hacking the CSS, I found that "margin-right: 10px" leads to the intended > style. But as simple as the change may sound, I could not find the proper > place in the source code to make this update. > old: > !screenshot-1.png! > new: > !screenshot-2.png! > of course the ":" indicates it, but that one is so small/narrow; > and looking at the start/end of the line also clears the doubt. but neither > are very intuitive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3090) expiry-queue cannot be unset
[ https://issues.apache.org/jira/browse/ARTEMIS-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp closed ARTEMIS-3090. -- > expiry-queue cannot be unset > > > Key: ARTEMIS-3090 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3090 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.16.0 >Reporter: Erwin Dondorp >Priority: Major > > By default, expiry-queue is set to "ExpiryQueue". > But it is not possible to replace the value with "xsd:nil" since the > expiry-queue setting is not nillable as specified in the corresponding XSD. > However, > src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java > implements a use-case to drop the message when no expiry-queue is set. > This use-case is hard to reach as one must then not set the expiry-queue for > the default address (#) and then set the expiry-queue for all other addresses. > I have 2 use-cases for which not expiry-queue should be set. the first is for > destinations that carry low-value data, and second for the ExpiryQueue > itself, to make sure that messages will eventually be discarded. The default > ExpiryQueue cannot expire messages since its expiry-queue points to itself. > I suggest that expiry-queue is made nillable, so that it can simply be > applied to individual addresses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3090) expiry-queue cannot be unset
[ https://issues.apache.org/jira/browse/ARTEMIS-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280060#comment-17280060 ] Erwin Dondorp commented on ARTEMIS-3090: [~jbertram] thank you! I thought that I tried all this and that it failed on the XSD validation. I was obviously wrong as the suggestion works properly. > expiry-queue cannot be unset > > > Key: ARTEMIS-3090 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3090 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.16.0 >Reporter: Erwin Dondorp >Priority: Major > > By default, expiry-queue is set to "ExpiryQueue". > But it is not possible to replace the value with "xsd:nil" since the > expiry-queue setting is not nillable as specified in the corresponding XSD. > However, > src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java > implements a use-case to drop the message when no expiry-queue is set. > This use-case is hard to reach as one must then not set the expiry-queue for > the default address (#) and then set the expiry-queue for all other addresses. > I have 2 use-cases for which not expiry-queue should be set. the first is for > destinations that carry low-value data, and second for the ExpiryQueue > itself, to make sure that messages will eventually be discarded. The default > ExpiryQueue cannot expire messages since its expiry-queue points to itself. > I suggest that expiry-queue is made nillable, so that it can simply be > applied to individual addresses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3103) Replace blowfish with a more secure encryption algorithm
[
https://issues.apache.org/jira/browse/ARTEMIS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-3103.
-
Resolution: Not A Problem
> Replace blowfish with a more secure encryption algorithm
> -
>
> Key: ARTEMIS-3103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3103
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Reporter: Ying Zhang
>Priority: Major
>
> The class {{org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec}}
> uses blowfish encrypting sensitive information.
> *Security Impact*:
> Blowfish's use of 64-bit block size (as opposed to e.g. AES's 128-bit block
> size) makes it vulnerable to [birthday
> attacks|https://en.wikipedia.org/wiki/Birthday_attack], particularly in
> contexts like [HTTPS|https://en.wikipedia.org/wiki/HTTPS]. In 2016, the
> SWEET32 attack demonstrated how to leverage birthday attacks to perform
> plaintext recovery (i.e. decrypting ciphertext) against ciphers with 64-bit
> block size.
> *Useful Resources*:
> https://cwe.mitre.org/data/definitions/319.html
> *Please share with us your opinions/comments if there is any:*
> Is the bug report helpful?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3103) Replace blowfish with a more secure encryption algorithm
[
https://issues.apache.org/jira/browse/ARTEMIS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280056#comment-17280056
]
Justin Bertram commented on ARTEMIS-3103:
-
There's a few things to note here:
# {{org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec}} is just
the _default_ codec. If any user wants a different implementation [the
documentation|http://activemq.apache.org/components/artemis/documentation/latest/masking-passwords.html#choosing-a-codec-for-password-masking]
outlines how to integrate it. Nobody is forced to use the default codec.
# Blowfish is used for "masking." This masking is a kind of a
pseudo-encryption where the same program must both encode _and_ decode the
data. Therefore, any user who has access to the broker's files to read the
masked data will have access to the codec implementation class as well. This
will allow them to fairly easily unmask data _regardless_ of the algorithm
used. Furthermore, any user who has access to the memory of the broker's JVM
will be able to find the decoded value(s) there as well _regardless_ of the
algorithm.
# Blowfish's weaknesses were known when the default codec was implemented, but
due to the fundamental nature of the way it is used those weaknesses don't
ultimately matter. Using a "better" algorithm won't actually increase security.
Similar to ARTEMIS-3070, this bug report is not helpful because it doesn't take
into account the larger context of how and why the Blowfish algorithm is used.
It seems to me that both this issue and ARTEMIS-3070 were generated based on
static code analysis. Please conduct a more thorough analysis before creating
any similar Jiras. Thanks!
> Replace blowfish with a more secure encryption algorithm
> -
>
> Key: ARTEMIS-3103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3103
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Reporter: Ying Zhang
>Priority: Major
>
> The class {{org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec}}
> uses blowfish encrypting sensitive information.
> *Security Impact*:
> Blowfish's use of 64-bit block size (as opposed to e.g. AES's 128-bit block
> size) makes it vulnerable to [birthday
> attacks|https://en.wikipedia.org/wiki/Birthday_attack], particularly in
> contexts like [HTTPS|https://en.wikipedia.org/wiki/HTTPS]. In 2016, the
> SWEET32 attack demonstrated how to leverage birthday attacks to perform
> plaintext recovery (i.e. decrypting ciphertext) against ciphers with 64-bit
> block size.
> *Useful Resources*:
> https://cwe.mitre.org/data/definitions/319.html
> *Please share with us your opinions/comments if there is any:*
> Is the bug report helpful?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3078) Log in on second web console closes first session, even for different brokers
[ https://issues.apache.org/jira/browse/ARTEMIS-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp closed ARTEMIS-3078. -- > Log in on second web console closes first session, even for different brokers > - > > Key: ARTEMIS-3078 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3078 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.16.0 >Reporter: Erwin Dondorp >Priority: Minor > > When there are 2 brokers running on the same host then logging in to the web > console of the second broker will cause an immediate logout in the session > for the first broker. > * Start 2 containers, echo one with an independent Artemis installation. Use > port mapping in docker to give each a unique port number. > * Open the web console for first broker and log in > * Open the web console for second broker and log in > * See that the first session automatically logs out and returns to the login > screen. > The affect is symmetric and can be repeated as many times as wanted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3103) Replace blowfish with a more secure encryption algorithm
[
https://issues.apache.org/jira/browse/ARTEMIS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-3103:
Description:
The class {{org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec}}
uses blowfish encrypting sensitive information.
*Security Impact*:
Blowfish's use of 64-bit block size (as opposed to e.g. AES's 128-bit block
size) makes it vulnerable to [birthday
attacks|https://en.wikipedia.org/wiki/Birthday_attack], particularly in
contexts like [HTTPS|https://en.wikipedia.org/wiki/HTTPS]. In 2016, the SWEET32
attack demonstrated how to leverage birthday attacks to perform plaintext
recovery (i.e. decrypting ciphertext) against ciphers with 64-bit block size.
*Useful Resources*:
https://cwe.mitre.org/data/definitions/319.html
*Please share with us your opinions/comments if there is any:*
Is the bug report helpful?
was:
In file
apache/activemq-artemis/blob/52263663c48082227916cc3477f8892d9f10134b/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/DefaultSensitiveStringCodec.javaThe
blowfish is used for encryption sensitive information
*Security Impact*:
Blowfish's use of 64-bit block size (as opposed to e.g. AES's 128-bit block
size) makes it vulnerable to [birthday
attacks|https://en.wikipedia.org/wiki/Birthday_attack], particularly in
contexts like [HTTPS|https://en.wikipedia.org/wiki/HTTPS]. In 2016, the SWEET32
attack demonstrated how to leverage birthday attacks to perform plaintext
recovery (i.e. decrypting ciphertext) against ciphers with 64-bit block size.
*Useful Resources*:
https://cwe.mitre.org/data/definitions/319.html
*Please share with us your opinions/comments if there is any:*
Is the bug report helpful?
> Replace blowfish with a more secure encryption algorithm
> -
>
> Key: ARTEMIS-3103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3103
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Reporter: Ying Zhang
>Priority: Major
>
> The class {{org.apache.activemq.artemis.utils.DefaultSensitiveStringCodec}}
> uses blowfish encrypting sensitive information.
> *Security Impact*:
> Blowfish's use of 64-bit block size (as opposed to e.g. AES's 128-bit block
> size) makes it vulnerable to [birthday
> attacks|https://en.wikipedia.org/wiki/Birthday_attack], particularly in
> contexts like [HTTPS|https://en.wikipedia.org/wiki/HTTPS]. In 2016, the
> SWEET32 attack demonstrated how to leverage birthday attacks to perform
> plaintext recovery (i.e. decrypting ciphertext) against ciphers with 64-bit
> block size.
> *Useful Resources*:
> https://cwe.mitre.org/data/definitions/319.html
> *Please share with us your opinions/comments if there is any:*
> Is the bug report helpful?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3104) Cannot send message from webconsole
[ https://issues.apache.org/jira/browse/ARTEMIS-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp closed ARTEMIS-3104. -- Resolution: Fixed > Cannot send message from webconsole > --- > > Key: ARTEMIS-3104 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3104 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: Web Console >Affects Versions: 2.16.0 >Reporter: Erwin Dondorp >Priority: Minor > > I'm currently logged in in the console using a username+password. > When trying to send a message to a queue using the web console, always the > following error occurs: > | Could not send message: java.lang.IllegalStateException : AMQ229031: Unable > to validate user from Management. Username: null; SSL certificate subject DN: > unavailable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3104) Cannot send message from webconsole
Erwin Dondorp created ARTEMIS-3104: -- Summary: Cannot send message from webconsole Key: ARTEMIS-3104 URL: https://issues.apache.org/jira/browse/ARTEMIS-3104 Project: ActiveMQ Artemis Issue Type: Wish Components: Web Console Affects Versions: 2.16.0 Reporter: Erwin Dondorp I'm currently logged in in the console using a username+password. When trying to send a message to a queue using the web console, always the following error occurs: | Could not send message: java.lang.IllegalStateException : AMQ229031: Unable to validate user from Management. Username: null; SSL certificate subject DN: unavailable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3103) Replace blowfish with a more secure encryption algorithm
Ying Zhang created ARTEMIS-3103: --- Summary: Replace blowfish with a more secure encryption algorithm Key: ARTEMIS-3103 URL: https://issues.apache.org/jira/browse/ARTEMIS-3103 Project: ActiveMQ Artemis Issue Type: Improvement Components: API Reporter: Ying Zhang In file apache/activemq-artemis/blob/52263663c48082227916cc3477f8892d9f10134b/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/DefaultSensitiveStringCodec.javaThe blowfish is used for encryption sensitive information *Security Impact*: Blowfish's use of 64-bit block size (as opposed to e.g. AES's 128-bit block size) makes it vulnerable to [birthday attacks|https://en.wikipedia.org/wiki/Birthday_attack], particularly in contexts like [HTTPS|https://en.wikipedia.org/wiki/HTTPS]. In 2016, the SWEET32 attack demonstrated how to leverage birthday attacks to perform plaintext recovery (i.e. decrypting ciphertext) against ciphers with 64-bit block size. *Useful Resources*: https://cwe.mitre.org/data/definitions/319.html *Please share with us your opinions/comments if there is any:* Is the bug report helpful? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3090) expiry-queue cannot be unset
[ https://issues.apache.org/jira/browse/ARTEMIS-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-3090. - Resolution: Cannot Reproduce > expiry-queue cannot be unset > > > Key: ARTEMIS-3090 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3090 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.16.0 >Reporter: Erwin Dondorp >Priority: Major > > By default, expiry-queue is set to "ExpiryQueue". > But it is not possible to replace the value with "xsd:nil" since the > expiry-queue setting is not nillable as specified in the corresponding XSD. > However, > src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java > implements a use-case to drop the message when no expiry-queue is set. > This use-case is hard to reach as one must then not set the expiry-queue for > the default address (#) and then set the expiry-queue for all other addresses. > I have 2 use-cases for which not expiry-queue should be set. the first is for > destinations that carry low-value data, and second for the ExpiryQueue > itself, to make sure that messages will eventually be discarded. The default > ExpiryQueue cannot expire messages since its expiry-queue points to itself. > I suggest that expiry-queue is made nillable, so that it can simply be > applied to individual addresses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3090) expiry-queue cannot be unset
[
https://issues.apache.org/jira/browse/ARTEMIS-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279996#comment-17279996
]
Justin Bertram commented on ARTEMIS-3090:
-
Do you have a test-case which reproduces what you've described? I ask because
I've tried to reproduce this and I can't.
If you want to "unset" the {{expiry-address}} for a particular address you
should be able to use {{}}. I wrote a quick test of this
scenario and everything worked as expected.
Also, there is already [logic in
place|https://github.com/apache/activemq-artemis/blob/2.16.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java#L2396]
to prevent expired messages from going back to the configured
{{expiry-address}}.
> expiry-queue cannot be unset
>
>
> Key: ARTEMIS-3090
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3090
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> By default, expiry-queue is set to "ExpiryQueue".
> But it is not possible to replace the value with "xsd:nil" since the
> expiry-queue setting is not nillable as specified in the corresponding XSD.
> However,
> src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
> implements a use-case to drop the message when no expiry-queue is set.
> This use-case is hard to reach as one must then not set the expiry-queue for
> the default address (#) and then set the expiry-queue for all other addresses.
> I have 2 use-cases for which not expiry-queue should be set. the first is for
> destinations that carry low-value data, and second for the ExpiryQueue
> itself, to make sure that messages will eventually be discarded. The default
> ExpiryQueue cannot expire messages since its expiry-queue points to itself.
> I suggest that expiry-queue is made nillable, so that it can simply be
> applied to individual addresses.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Deleted] (AMQNET-659) SITUS JUDI SLOT ONLINE
[ https://issues.apache.org/jira/browse/AMQNET-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon deleted AMQNET-659: -- > SITUS JUDI SLOT ONLINE > -- > > Key: AMQNET-659 > URL: https://issues.apache.org/jira/browse/AMQNET-659 > Project: ActiveMQ .Net > Issue Type: New Feature > Environment: Permainan Game [Slot Online|http://198.187.29.230/] dari > Joker Gaming ini menawarkan beragam tema dan variasi permainan yang populer > saat ini, bahkan mengambil tema dari cerita fantasi, legenda ataupun fiksi. > Jenis permainan dan fitur yang ditawarkan juga sangat menarik dan dilengkapi > dengan fitur progressive Jackpot, imana nilai bonus Jackpot yang ada, akan > terus bertambah seiring waktu. Jadi semakin banyak anda bermain maka bonusnya > akan cepat bertambah. Fitur ini adalah salah satu alasan yang membuat > permainan Joker Slot ini memiliki banyak peminat. > Agar bisa memainkan permainan terbaik dari Slot Game Online, tentu QQkini > konsisten untuk selalu mengupdate permainan terbaru 2020 dan terbaik seperti > Joker123 Slot. Selain itu QQkini juga menyediakan permainan JDB Slot, > Habanero, Spadegaming, Pragmatic Slot Online, Playtech, Microgaming, dll yang > tentunya akan membuat Anda semakin mudah untuk meraih kemenangan dan > keuntungan dalam permainan judi slot online. > Keuntungan dari bergabung di [Situs Slot Online|http://198.187.29.230/] > Terpercaya adalah Promo Bonus yang melimpah dan kesempatan meraih jackpot > yang lebih besar sehingga Anda mudah meraih kemenangan dalam permainan judi > joker slot online. Dengan layananan customer service profesional, cantik dan > ramah yang support 24 jam, menunjukan [QQkini|http://198.187.29.230/] sebagai > Situs Judi Online Terpercaya yang selalu memberikan yang terbaik bagi para > pecinta judi slot online Indonesia. >Reporter: QQKINI Agen Judi Online >Priority: Major > Labels: documentation, github-import, newbie, patch, performance > > Jika Anda mencari [Situs Slot Online|http://198.187.29.230/] Uang Asli dan > Deposit Pulsa Terbaik Tanpa Potongan, QQkini adalah pilihan terpercaya dan > sangat cocok untuk Anda. Selain merupakan penyedia jasa layanan Slot Joker123 > dan [Judi Bola Online|http://198.187.29.230/] terlengkap, kami juga > memberikan minimal deposit termurah, hanya dengan Rp 20.000, Anda sudah bisa > bermain sepuasnya di situs Judi Online Terpercaya di Asia ini. > QQkini merupakan Situs Slot Online 100% fairplay yang tentunya akan selalu > membayar berapapun kemenangan Anda tanpa potongan apapun. Oleh sebab itu Anda > tidak perlu merasa ragu untuk bergabung dengan QQkini [Situs Judi Mesin Slot > Online|http://198.187.29.230/] dan [Judi Bola88 > |http://198.187.29.230/]Terpercaya yang sudah berlisensi resmi PACGOR. > Syarat dan ketentuan untuk bermain permainan Joker123 Slot Online dan Joker > Gaming yang bisa Anda mainkan di smartphone Anda, dimanan membutuhkan sistem > versi Android atau IOS dengan jaringan intenet yang stabil dan lancar. > Permainan Situs Slot Online, Joker123 ini juga bisa Anda mainkan baik > menggunakan browser ataupun dengan mendowload aplikasi sehingga Anda bisa > bermain dengan nyaman dan santai. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Deleted] (AMQNET-658) SITUS SLOT ONLINE TERLENGKAP DAN TERPERCAYA
[ https://issues.apache.org/jira/browse/AMQNET-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon deleted AMQNET-658: -- > SITUS SLOT ONLINE TERLENGKAP DAN TERPERCAYA > --- > > Key: AMQNET-658 > URL: https://issues.apache.org/jira/browse/AMQNET-658 > Project: ActiveMQ .Net > Issue Type: New Feature > Environment: Permainan Game [Slot Online|http://198.187.29.230/] dari > Joker Gaming ini menawarkan beragam tema dan variasi permainan yang populer > saat ini, bahkan mengambil tema dari cerita fantasi, legenda ataupun fiksi. > Jenis permainan dan fitur yang ditawarkan juga sangat menarik dan dilengkapi > dengan fitur progressive Jackpot, imana nilai bonus Jackpot yang ada, akan > terus bertambah seiring waktu. Jadi semakin banyak anda bermain maka bonusnya > akan cepat bertambah. Fitur ini adalah salah satu alasan yang membuat > permainan Joker Slot ini memiliki banyak peminat. > Agar bisa memainkan permainan terbaik dari Slot Game Online, tentu QQkini > konsisten untuk selalu mengupdate permainan terbaru 2020 dan terbaik seperti > Joker123 Slot. Selain itu QQkini juga menyediakan permainan JDB Slot, > Habanero, Spadegaming, Pragmatic Slot Online, Playtech, Microgaming, dll yang > tentunya akan membuat Anda semakin mudah untuk meraih kemenangan dan > keuntungan dalam permainan judi slot online. > Keuntungan dari bergabung di [Situs Slot Online|http://198.187.29.230/] > Terpercaya adalah Promo Bonus yang melimpah dan kesempatan meraih jackpot > yang lebih besar sehingga Anda mudah meraih kemenangan dalam permainan judi > joker slot online. Dengan layananan customer service profesional, cantik dan > ramah yang support 24 jam, menunjukan [QQkini|http://198.187.29.230/] sebagai > Situs Judi Online Terpercaya yang selalu memberikan yang terbaik bagi para > pecinta judi slot online Indonesia. >Reporter: QQKINI Agen Judi Online >Priority: Major > Labels: documentation, github-import, newbie, patch, performance > > h3. *JOKER123 | LOGIN JOKER123 | LINK JOKER123 | JOKER GAMING | JOKER SLOT | > ALTERNATIF LOGIN JOKER123 | SLOT ONLINE | DOWNLOAD APK JOKER 123 | DAFTAR > JOKER123 |* > [QQkini|http://198.187.29.230/] adalah Situs Slot Online Terlengkap, Terbaik > dan Terpercaya di Indonesia dengan beragam permainan [judi > online|http://198.187.29.230/] yang membuat taruhan terasa menarik dan seru. > Dengan hanya 1 user ID saja, Anda sudah bisa bermain permainan JDB Slot > Online, Joker123, Joker Gaming, Pragmatic Play, Habanero, Spadegaming, > [Casino338|http://198.187.29.230/], Taruhan Bola, Tembak Ikan, Roulette, > Poker dan Togel Online. > [Slot Joker123|http://198.187.29.230/] merupakan permainan selingan yang ada > di Casino besar di dunia. Dimana banyak pemain yang mengharapkan mendapatkan > jackpot mengejutkan dengan jumlah yang fantastis. QQkini sebagai Situs Slot > Joker Online terpercaya, sudah memiliki sertifikat Pagcor yang diperoleh dari > usaha [Agen JokerGaming|http://198.187.29.230/] untuk selalu memberikan > service terbaik sehingga bisa menjadi salah satu permainan slot game online > terbaik di dunia. > *Situs Joker123 Slot Online QQkini sudah terbukti mempunyai kredibilitas > tinggi dan pantas sebagai [Situs Judi Online|http://198.187.29.230/] yang > menghadirkan permainan Joker Slot Online ini kepada para* pecinta judi slot > online di Indonesia. > QQkini Situs Slot online no 1 di Indonesia yang sudah memililiki puluhan ribu > member aktif dan menghasilkan ratusan ribu transaksi online setiap harinya. > Oleh sebab itu Situs Slot Online QQkini amat berterimakasih kepada semua > penggemar Joker Slot Online yang sangat mempercayai kami untuk melayani Anda > dalam permainan Situs Slot Online Terlengkap dan Terpercaya di Indonesia. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279935#comment-17279935 ] ASF subversion and git services commented on AMQNET-637: Commit d045738829aaf8dda169b8cb0afacbe2c856307a in activemq-nms-api's branch refs/heads/master from lukeabsent [ https://gitbox.apache.org/repos/asf?p=activemq-nms-api.git;h=d045738 ] AMQNET-637 NMS 2.0 More async methods > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 10h 20m > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279937#comment-17279937 ] ASF subversion and git services commented on AMQNET-637: Commit 1852cf70b7de3d2279fd74b6d49b3b5c153d944f in activemq-nms-api's branch refs/heads/master from Michael André Pearce [ https://gitbox.apache.org/repos/asf?p=activemq-nms-api.git;h=1852cf7 ] Merge pull request #18 from lukeabsent/AMQNET-637 AMQNET-637 NMS 2.0 More async methods > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 10h 20m > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279936#comment-17279936 ] ASF subversion and git services commented on AMQNET-637: Commit 1852cf70b7de3d2279fd74b6d49b3b5c153d944f in activemq-nms-api's branch refs/heads/master from Michael André Pearce [ https://gitbox.apache.org/repos/asf?p=activemq-nms-api.git;h=1852cf7 ] Merge pull request #18 from lukeabsent/AMQNET-637 AMQNET-637 NMS 2.0 More async methods > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 10h 20m > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?focusedWorklogId=548820=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548820 ] ASF GitHub Bot logged work on AMQNET-637: - Author: ASF GitHub Bot Created on: 05/Feb/21 19:22 Start Date: 05/Feb/21 19:22 Worklog Time Spent: 10m Work Description: michaelandrepearce merged pull request #18: URL: https://github.com/apache/activemq-nms-api/pull/18 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548820) Time Spent: 10.5h (was: 10h 20m) > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 10.5h > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3044) Add Artemis web console tests
[
https://issues.apache.org/jira/browse/ARTEMIS-3044?focusedWorklogId=548782=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548782
]
ASF GitHub Bot logged work on ARTEMIS-3044:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 17:39
Start Date: 05/Feb/21 17:39
Worklog Time Spent: 10m
Work Description: clebertsuconic edited a comment on pull request #3390:
URL: https://github.com/apache/activemq-artemis/pull/3390#issuecomment-774179562
I ran this on our CI, and I got a few failures:
Test Name | Duration | Age
-- | -- | --
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLogin[browserOptions=Capabilities
{browserName: chrome}] | 2.8 sec | 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLogin[browserOptions=Capabilities
{browserName: chrome}] | 2.8 sec | 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLoginBrand[browserOptions=Capabilities
{browserName: chrome}] | 2.4 sec | 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLogin[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] | 2.4 sec | 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLoginBrand[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] | 2.3 sec | 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testAutoCreatedQueue[browserOptions=Capabilities
{browserName: chrome}] | 2.9 sec | 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testDefaultQueues[browserOptions=Capabilities
{browserName: chrome}] | 2.3 sec | 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testAutoCreatedQueue[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] | 2.8 sec | 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testDefaultQueues[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] | 2.3 sec | 1
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548782)
Time Spent: 0.5h (was: 20m)
> Add Artemis web console tests
> -
>
> Key: ARTEMIS-3044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3044
> Project: ActiveMQ Artemis
> Issue Type: Test
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3044) Add Artemis web console tests
[
https://issues.apache.org/jira/browse/ARTEMIS-3044?focusedWorklogId=548780=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548780
]
ASF GitHub Bot logged work on ARTEMIS-3044:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 17:38
Start Date: 05/Feb/21 17:38
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on pull request #3390:
URL: https://github.com/apache/activemq-artemis/pull/3390#issuecomment-774179562
I ran this on our CI, and I got a few failures:
Test Name
Duration
Age
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLogin[browserOptions=Capabilities
{browserName: chrome}] 2.8 sec 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLogin[browserOptions=Capabilities
{browserName: chrome}] 2.8 sec 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLoginBrand[browserOptions=Capabilities
{browserName: chrome}] 2.4 sec 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLogin[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] 2.4 sec 1
org.apache.activemq.artemis.tests.smoke.console.LoginTest.testLoginBrand[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] 2.3 sec 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testAutoCreatedQueue[browserOptions=Capabilities
{browserName: chrome}] 2.9 sec 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testDefaultQueues[browserOptions=Capabilities
{browserName: chrome}] 2.3 sec 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testAutoCreatedQueue[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] 2.8 sec 1
org.apache.activemq.artemis.tests.smoke.console.QueuesTest.testDefaultQueues[browserOptions=Capabilities
{acceptInsecureCerts: true, browserName: firefox}] 2.3 sec 1
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548780)
Time Spent: 20m (was: 10m)
> Add Artemis web console tests
> -
>
> Key: ARTEMIS-3044
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3044
> Project: ActiveMQ Artemis
> Issue Type: Test
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279832#comment-17279832
]
Justin Bertram commented on ARTEMIS-2886:
-
[~luisalves00], I already linked ARTEMIS-3102 to this issue. Please put any
comments relevant to ARTEMIS-3102 on that issue rather than this one. It's
going to get really confusing to have discussion in both places.
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3102) ActiveMQSecurityManager5 should disconnect user when his authentication is not valid anymore
[
https://issues.apache.org/jira/browse/ARTEMIS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279812#comment-17279812
]
Justin Bertram commented on ARTEMIS-3102:
-
At this point I'm not convinced that the connection should be forcibly closed.
The {{null}} subject will never be authorized to do _anything_ so there's no
security issue, and as t[his comment on
ARTEMIS-2886|https://issues.apache.org/jira/browse/ARTEMIS-2886?focusedCommentId=17279712=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17279712]
indicates the proper {{javax.jms.JMSSecurityException}} is thrown on the
client. It seems reasonable for the client to deal with this exception and
reconnect if necessary.
> ActiveMQSecurityManager5 should disconnect user when his authentication is
> not valid anymore
>
>
> Key: ARTEMIS-3102
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3102
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Luís Alves
>Priority: Major
>
> On the following code block:
> {code:java}
> final Boolean validated;
> if (securityManager instanceof ActiveMQSecurityManager5) {
> Subject subject = getSubjectForAuthorization(session,
> ((ActiveMQSecurityManager5) securityManager));
> validated = ((ActiveMQSecurityManager5)
> securityManager).authorize(subject, roles, checkType, fqqn != null ?
> fqqn.toString() : bareAddress.toString());
> }
> {code}
> when the retrieved Subject is null (means the user cannot authenticate
> anymore) the connection should be terminated. If not this will cause that the
> user is not authorized to do the operation, but in fact he shouldn't not even
> be allowed to connect.
> Quoting [~gtully] on https://issues.apache.org/jira/browse/ARTEMIS-2886 where
> he explains very well the problem:
> {quote}I don't think your use case is unique to OpenID, the cached ldap jaas
> login module can find that permissions have been removed from ldap at runtime
> and that authorization has been removed. Once the cache expires and jaas is
> again asked, it too will return a null subject i think and subsequent
> operations will result in exceptions in the same way. I don't know how it
> will behave if a user is no longer valid.
> typically a security exception on initial connection, a failure to
> authenticate, will cause the connection to be rejected, the connection to
> close. But security exceptions are expected at runtime if you have access to
> some resources and not others and are not aware of that. If permissions
> change at runtime, some variation here is ok.
> If however, a users is no longer able to authenticate (in your case, the
> token has expired and cannot be renewed, then we need to drop the connection.
> as a straw man design:
> We may have to change the use of Subject in the code, a valid subject is non
> null and has a valid artemis user principal. We need to check for the
> presence of the user principal. That can indicate if the authentication is
> still valid. If we can proceed with authorization checks.
> At runtime, we may find that the non null subject becomes invalid b/c the
> artemis principal is removed and that should cause any authorisation attempt
> to fail and the connection to error out or be forcefully closed.
> I think we need to do something like this.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279809#comment-17279809
]
Luís Alves commented on ARTEMIS-2886:
-
Created [ARTEMIS-3102|https://issues.apache.org/jira/browse/ARTEMIS-3102].
Throwing a Runtime Exception (cannot send any checked exception) will not do
the trick as the connection is not terminated. The client just receive a
GENERIC_EXCEPTION and the connection remains in the pool.
For now, my solution is to trust the token even when it's expired, but this has
a lot of downsides.
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3102) ActiveMQSecurityManager5 should disconnect user when his authentication is not valid anymore
Luís Alves created ARTEMIS-3102:
---
Summary: ActiveMQSecurityManager5 should disconnect user when his
authentication is not valid anymore
Key: ARTEMIS-3102
URL: https://issues.apache.org/jira/browse/ARTEMIS-3102
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: Broker
Affects Versions: 2.16.0
Reporter: Luís Alves
On the following code block:
{code:java}
final Boolean validated;
if (securityManager instanceof ActiveMQSecurityManager5) {
Subject subject = getSubjectForAuthorization(session,
((ActiveMQSecurityManager5) securityManager));
validated = ((ActiveMQSecurityManager5)
securityManager).authorize(subject, roles, checkType, fqqn != null ?
fqqn.toString() : bareAddress.toString());
}
{code}
when the retrieved Subject is null (means the user cannot authenticate anymore)
the connection should be terminated. If not this will cause that the user is
not authorized to do the operation, but in fact he shouldn't not even be
allowed to connect.
Quoting [~gtully] on https://issues.apache.org/jira/browse/ARTEMIS-2886 where
he explains very well the problem:
{quote}I don't think your use case is unique to OpenID, the cached ldap jaas
login module can find that permissions have been removed from ldap at runtime
and that authorization has been removed. Once the cache expires and jaas is
again asked, it too will return a null subject i think and subsequent
operations will result in exceptions in the same way. I don't know how it will
behave if a user is no longer valid.
typically a security exception on initial connection, a failure to
authenticate, will cause the connection to be rejected, the connection to
close. But security exceptions are expected at runtime if you have access to
some resources and not others and are not aware of that. If permissions change
at runtime, some variation here is ok.
If however, a users is no longer able to authenticate (in your case, the token
has expired and cannot be renewed, then we need to drop the connection.
as a straw man design:
We may have to change the use of Subject in the code, a valid subject is non
null and has a valid artemis user principal. We need to check for the presence
of the user principal. That can indicate if the authentication is still valid.
If we can proceed with authorization checks.
At runtime, we may find that the non null subject becomes invalid b/c the
artemis principal is removed and that should cause any authorisation attempt to
fail and the connection to error out or be forcefully closed.
I think we need to do something like this.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548763=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548763
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 16:57
Start Date: 05/Feb/21 16:57
Worklog Time Spent: 10m
Work Description: laeubi commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r571110875
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,11 +17,41 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
+import java.util.Comparator;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.ServiceLoader;
+
public class MechanismFinder {
- public static String[] KNOWN_MECHANISMS = new String[]{PlainSASL.NAME,
AnonymousServerSASL.NAME};
+ private static final Map FACTORY_MAP = new
HashMap<>();
+ private static final Comparator
PRECEDENCE_COMPARATOR =
+ (f1, f2) -> Integer.compare(f1.getPrecedence(), f2.getPrecedence());
+
+ static {
+ ServiceLoader serviceLoader =
+ ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
+ for (ServerSASLFactory factory : serviceLoader) {
+ FACTORY_MAP.merge(factory.getMechanism(), factory, (f1, f2) -> {
+if (f2.getPrecedence() > f1.getPrecedence()) {
+ return f2;
+} else {
+ return f1;
+}
+ });
+ }
+ }
+
+ public static String[] getDefaultMechanisms() {
+ return FACTORY_MAP.values()
+.stream()
+.filter(ServerSASLFactory::isDefaultPermitted)
+.sorted(PRECEDENCE_COMPARATOR.reversed())
+.map(ServerSASLFactory::getMechanism)
+.toArray(String[]::new);
Review comment:
The value is just read once on connector creation if I see right,
nerveless I'll extract this so it is only computed once.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548763)
Time Spent: 2.5h (was: 2h 20m)
> Generic integration with SASL Frameworks
>
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Clebert Suconic
>Priority: Critical
> Fix For: unscheduled
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should
> investigate if there is any interest extending SASL into any other protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548755=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548755
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 16:44
Start Date: 05/Feb/21 16:44
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r571102054
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,11 +17,41 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
+import java.util.Comparator;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.ServiceLoader;
+
public class MechanismFinder {
- public static String[] KNOWN_MECHANISMS = new String[]{PlainSASL.NAME,
AnonymousServerSASL.NAME};
+ private static final Map FACTORY_MAP = new
HashMap<>();
+ private static final Comparator
PRECEDENCE_COMPARATOR =
+ (f1, f2) -> Integer.compare(f1.getPrecedence(), f2.getPrecedence());
+
+ static {
+ ServiceLoader serviceLoader =
+ ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
+ for (ServerSASLFactory factory : serviceLoader) {
+ FACTORY_MAP.merge(factory.getMechanism(), factory, (f1, f2) -> {
+if (f2.getPrecedence() > f1.getPrecedence()) {
+ return f2;
+} else {
+ return f1;
+}
+ });
+ }
+ }
+
+ public static String[] getDefaultMechanisms() {
+ return FACTORY_MAP.values()
+.stream()
+.filter(ServerSASLFactory::isDefaultPermitted)
+.sorted(PRECEDENCE_COMPARATOR.reversed())
+.map(ServerSASLFactory::getMechanism)
+.toArray(String[]::new);
Review comment:
This is still being evaluated on every get, computing the same result
over and over for every connection. Determine the result while creating the map
and this can then simply return 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548755)
Time Spent: 2h 20m (was: 2h 10m)
> Generic integration with SASL Frameworks
>
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Clebert Suconic
>Priority: Critical
> Fix For: unscheduled
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should
> investigate if there is any interest extending SASL into any other protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3093) Message Order broken with Core Protocol when rolling back transactions
[ https://issues.apache.org/jira/browse/ARTEMIS-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Behm updated ARTEMIS-3093: --- Affects Version/s: 2.16.0 > Message Order broken with Core Protocol when rolling back transactions > -- > > Key: ARTEMIS-3093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3093 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.16.0 >Reporter: John Behm >Priority: Critical > > ARTEMIS-2458 > This issue still persists. > > Consuming from a queue with two threads with distinct sessions while rolling > back directly in each thread when receiving a message breaks the whole order > of the queue. Even with delays of 500ms. > The queue/addresse is configured as ANYCAST queue. > > (In 2.10 this issue persists as well.) > Basic Test setup is like this: > You have a non-clustered single instance of Artemis. > You do have a redelivery-delay of 0. > You fill an anycast queue with 1000/1 ordered messages. > You disconnect your producer and start the two or more consumers that try to > fetch all of the messages from that exact same queue, but can only get one, > as you always roll back the session. > Each time any of those two(or more) consumers receives a message, they > rollback the session instantly and sleep 0 to 500 ms. > After rolling back every time you receive a message on any of your consumer > threads, you expect to always get the message with the content "0". > After like ten iterations of this ping-pong rollback between your two > consumer threads, you start to get completely random messages, not even > within the range of 0 through 10, but completely arbitrary ones from within > the queue. > You disconnect your consumers and try dumping the queue. You get a completely > unordered message queue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3093) Message Order broken with Core Protocol when rolling back transactions
[ https://issues.apache.org/jira/browse/ARTEMIS-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Behm updated ARTEMIS-3093: --- Component/s: Broker > Message Order broken with Core Protocol when rolling back transactions > -- > > Key: ARTEMIS-3093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.16.0 >Reporter: John Behm >Priority: Critical > > ARTEMIS-2458 > This issue still persists. > > Consuming from a queue with two threads with distinct sessions while rolling > back directly in each thread when receiving a message breaks the whole order > of the queue. Even with delays of 500ms. > The queue/addresse is configured as ANYCAST queue. > > (In 2.10 this issue persists as well.) > Basic Test setup is like this: > You have a non-clustered single instance of Artemis. > You do have a redelivery-delay of 0. > You fill an anycast queue with 1000/1 ordered messages. > You disconnect your producer and start the two or more consumers that try to > fetch all of the messages from that exact same queue, but can only get one, > as you always roll back the session. > Each time any of those two(or more) consumers receives a message, they > rollback the session instantly and sleep 0 to 500 ms. > After rolling back every time you receive a message on any of your consumer > threads, you expect to always get the message with the content "0". > After like ten iterations of this ping-pong rollback between your two > consumer threads, you start to get completely random messages, not even > within the range of 0 through 10, but completely arbitrary ones from within > the queue. > You disconnect your consumers and try dumping the queue. You get a completely > unordered message queue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279775#comment-17279775
]
Justin Bertram commented on ARTEMIS-2886:
-
FWIW, the PR for this issue was merged and released in 2.16.0 and this issue is
closed. You should take this to an ActiveMQ mailing list or create a new Jira.
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3099) Incorrect default producer-window-size on bridge in broker.xml
[
https://issues.apache.org/jira/browse/ARTEMIS-3099?focusedWorklogId=548717=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548717
]
ASF GitHub Bot logged work on ARTEMIS-3099:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 15:51
Start Date: 05/Feb/21 15:51
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request #3433:
URL: https://github.com/apache/activemq-artemis/pull/3433
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548717)
Remaining Estimate: 0h
Time Spent: 10m
> Incorrect default producer-window-size on bridge in broker.xml
> --
>
> Key: ARTEMIS-3099
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3099
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Mikhail Lukyanov
>Assignee: Justin Bertram
>Priority: Major
> Attachments: image-2021-02-05-11-11-30-420.png,
> image-2021-02-05-11-22-14-901.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I deploy bridge via ActiveMQServer.deployBridge(BridgeConfiguration config)
> like
>
> {code:java}
> server.deployBridge(new BridgeConfiguration()
> .setName("myBridge")
> .setQueueName("myQueue")
> .setForwardingAddress("myFowardingAddress")
> .setStaticConnectors(List.of("in-vm")));{code}
> And default *producerWindowSize* set to -1
>
> !image-2021-02-05-11-11-30-420.png!
> Then I set this bridge to broker.xml like
> {code:java}
>
>
> myQueue
> myFowardingAddress
>
> in-vm
>
>
> {code}
> And after broker reboot, I get bridge with *producerWindowSize=10485760*
> !image-2021-02-05-11-22-14-901.png!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ARTEMIS-3099) Incorrect default producer-window-size on bridge in broker.xml
[
https://issues.apache.org/jira/browse/ARTEMIS-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-3099:
---
Assignee: Justin Bertram
> Incorrect default producer-window-size on bridge in broker.xml
> --
>
> Key: ARTEMIS-3099
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3099
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Mikhail Lukyanov
>Assignee: Justin Bertram
>Priority: Major
> Attachments: image-2021-02-05-11-11-30-420.png,
> image-2021-02-05-11-22-14-901.png
>
>
> I deploy bridge via ActiveMQServer.deployBridge(BridgeConfiguration config)
> like
>
> {code:java}
> server.deployBridge(new BridgeConfiguration()
> .setName("myBridge")
> .setQueueName("myQueue")
> .setForwardingAddress("myFowardingAddress")
> .setStaticConnectors(List.of("in-vm")));{code}
> And default *producerWindowSize* set to -1
>
> !image-2021-02-05-11-11-30-420.png!
> Then I set this bridge to broker.xml like
> {code:java}
>
>
> myQueue
> myFowardingAddress
>
> in-vm
>
>
> {code}
> And after broker reboot, I get bridge with *producerWindowSize=10485760*
> !image-2021-02-05-11-22-14-901.png!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3099) Incorrect default producer-window-size on bridge in broker.xml
[
https://issues.apache.org/jira/browse/ARTEMIS-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-3099:
Summary: Incorrect default producer-window-size on bridge in broker.xml
(was: Bridge default producerWindowSize (-1) set at
ActiveMQServer.deployBridge(BridgeConfiguration config) changes after broker
reboot to 10485760)
> Incorrect default producer-window-size on bridge in broker.xml
> --
>
> Key: ARTEMIS-3099
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3099
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Mikhail Lukyanov
>Priority: Major
> Attachments: image-2021-02-05-11-11-30-420.png,
> image-2021-02-05-11-22-14-901.png
>
>
> I deploy bridge via ActiveMQServer.deployBridge(BridgeConfiguration config)
> like
>
> {code:java}
> server.deployBridge(new BridgeConfiguration()
> .setName("myBridge")
> .setQueueName("myQueue")
> .setForwardingAddress("myFowardingAddress")
> .setStaticConnectors(List.of("in-vm")));{code}
> And default *producerWindowSize* set to -1
>
> !image-2021-02-05-11-11-30-420.png!
> Then I set this bridge to broker.xml like
> {code:java}
>
>
> myQueue
> myFowardingAddress
>
> in-vm
>
>
> {code}
> And after broker reboot, I get bridge with *producerWindowSize=10485760*
> !image-2021-02-05-11-22-14-901.png!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548698=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548698
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 15:19
Start Date: 05/Feb/21 15:19
Worklog Time Spent: 10m
Work Description: laeubi commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r571041960
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,31 +17,48 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
-import java.util.Arrays;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
import java.util.HashMap;
+import java.util.List;
import java.util.Map;
import java.util.ServiceLoader;
-import java.util.stream.Stream;
public class MechanismFinder {
- private static final String[] DEFAULT_MECHANISMS = new String[]
{PlainSASL.NAME, AnonymousServerSASL.NAME};
-
- private static final Map FACTORY_MAP = new
HashMap<>();
+ private static final Map> FACTORY_MAP = new
HashMap<>();
+ private static final Comparator
PRECEDENCE_COMPARATOR =
+ (f1, f2) -> f1.getPrecedence() - f2.getPrecedence();
static {
ServiceLoader serviceLoader =
ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
for (ServerSASLFactory factory : serviceLoader) {
- FACTORY_MAP.put(factory.getMechanism(), factory);
+ List list =
FACTORY_MAP.computeIfAbsent(factory.getMechanism(), k -> new ArrayList<>());
+ list.add(factory);
+ }
+ for (List factories : FACTORY_MAP.values()) {
+ Collections.sort(factories, PRECEDENCE_COMPARATOR);
}
}
- public static String[] getKnownMechanisms() {
- return Stream.concat(Arrays.stream(DEFAULT_MECHANISMS),
FACTORY_MAP.keySet().stream()).toArray(String[]::new);
+ public static String[] getDefaultMechanisms() {
+ return FACTORY_MAP.values()
+.stream()
+.flatMap(List::stream)
+.sorted(PRECEDENCE_COMPARATOR)
+.map(ServerSASLFactory::getMechanism)
+.distinct()
+.toArray(String[]::new);
Review comment:
you are right, I'll adjust this.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548698)
Time Spent: 2h 10m (was: 2h)
> Generic integration with SASL Frameworks
>
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Clebert Suconic
>Priority: Critical
> Fix For: unscheduled
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should
> investigate if there is any interest extending SASL into any other protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548695=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548695 ] ASF GitHub Bot logged work on ARTEMIS-33: - Author: ASF GitHub Bot Created on: 05/Feb/21 15:15 Start Date: 05/Feb/21 15:15 Worklog Time Spent: 10m Work Description: gemmellr commented on pull request #3432: URL: https://github.com/apache/activemq-artemis/pull/3432#issuecomment-774094039 > > > I have updated the PR but can't see why the build fails any idea? It seems to be unrelated, I see similar sporadically failures in a lot in other recent prior builds. Perhaps the test failure to look at before release @clebertsuconic (perhaps its even the thing you already noted looking at). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548695) Time Spent: 2h (was: 1h 50m) > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Clebert Suconic >Priority: Critical > Fix For: unscheduled > > Time Spent: 2h > Remaining Estimate: 0h > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548691=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548691
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 15:10
Start Date: 05/Feb/21 15:10
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r571025540
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,31 +17,48 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
-import java.util.Arrays;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
import java.util.HashMap;
+import java.util.List;
import java.util.Map;
import java.util.ServiceLoader;
-import java.util.stream.Stream;
public class MechanismFinder {
- private static final String[] DEFAULT_MECHANISMS = new String[]
{PlainSASL.NAME, AnonymousServerSASL.NAME};
-
- private static final Map FACTORY_MAP = new
HashMap<>();
+ private static final Map> FACTORY_MAP = new
HashMap<>();
+ private static final Comparator
PRECEDENCE_COMPARATOR =
+ (f1, f2) -> f1.getPrecedence() - f2.getPrecedence();
static {
ServiceLoader serviceLoader =
ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
for (ServerSASLFactory factory : serviceLoader) {
- FACTORY_MAP.put(factory.getMechanism(), factory);
+ List list =
FACTORY_MAP.computeIfAbsent(factory.getMechanism(), k -> new ArrayList<>());
+ list.add(factory);
+ }
+ for (List factories : FACTORY_MAP.values()) {
+ Collections.sort(factories, PRECEDENCE_COMPARATOR);
Review comment:
Maintaining a map of lists seems unecessarily complicated. Cant you jsut
merge the seen factory objects and keep the one with the higher precedence?
This would simplify everything done afterwards too.
Note I am not seeing use of the 'isDefaultPerimitted' bits from the factory,
which presumably means this might currently be advertising GSSAPI and EXTERNAL
by default when it definitely shouldnt.
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,31 +17,48 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
-import java.util.Arrays;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
import java.util.HashMap;
+import java.util.List;
import java.util.Map;
import java.util.ServiceLoader;
-import java.util.stream.Stream;
public class MechanismFinder {
- private static final String[] DEFAULT_MECHANISMS = new String[]
{PlainSASL.NAME, AnonymousServerSASL.NAME};
-
- private static final Map FACTORY_MAP = new
HashMap<>();
+ private static final Map> FACTORY_MAP = new
HashMap<>();
+ private static final Comparator
PRECEDENCE_COMPARATOR =
+ (f1, f2) -> f1.getPrecedence() - f2.getPrecedence();
static {
ServiceLoader serviceLoader =
ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
for (ServerSASLFactory factory : serviceLoader) {
- FACTORY_MAP.put(factory.getMechanism(), factory);
+ List list =
FACTORY_MAP.computeIfAbsent(factory.getMechanism(), k -> new ArrayList<>());
+ list.add(factory);
+ }
+ for (List factories : FACTORY_MAP.values()) {
+ Collections.sort(factories, PRECEDENCE_COMPARATOR);
}
}
- public static String[] getKnownMechanisms() {
- return Stream.concat(Arrays.stream(DEFAULT_MECHANISMS),
FACTORY_MAP.keySet().stream()).toArray(String[]::new);
+ public static String[] getDefaultMechanisms() {
+ return FACTORY_MAP.values()
+.stream()
+.flatMap(List::stream)
+.sorted(PRECEDENCE_COMPARATOR)
+.map(ServerSASLFactory::getMechanism)
+.distinct()
+.toArray(String[]::new);
}
public static ServerSASLFactory getFactory(String mechanism) {
- return FACTORY_MAP.get(mechanism);
+ List list = FACTORY_MAP.get(mechanism);
+ if (list == null || list.isEmpty()) {
+ return null;
+ }
+ // return mechanism with highest precedence if multiple are registered
+ return list.get(0);
Review comment:
This could be reduced to a simple map lookup after prior comments.
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,31 +17,48 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
-import
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548676=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548676 ] ASF GitHub Bot logged work on ARTEMIS-33: - Author: ASF GitHub Bot Created on: 05/Feb/21 15:01 Start Date: 05/Feb/21 15:01 Worklog Time Spent: 10m Work Description: laeubi commented on pull request #3432: URL: https://github.com/apache/activemq-artemis/pull/3432#issuecomment-774085809 I have updated the PR but can't see why the build fails any idea? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548676) Time Spent: 1h 40m (was: 1.5h) > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Clebert Suconic >Priority: Critical > Fix For: unscheduled > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3101) Java formating rules does not comply with checkstyle
Christoph Läubrich created ARTEMIS-3101: --- Summary: Java formating rules does not comply with checkstyle Key: ARTEMIS-3101 URL: https://issues.apache.org/jira/browse/ARTEMIS-3101 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Christoph Läubrich I copied files according to: https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/formatting.md but it seems the files are out of date. Eclipse (2020-12) complains on save about invalid properties in cleanup and formatting rules. Beside that, not all whitespace rules are applied correctly (e.g. lamdas and array initializes) so checkstyle gets mad and one has to correct whitespaces by hand. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?focusedWorklogId=548655=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548655 ] ASF GitHub Bot logged work on AMQNET-637: - Author: ASF GitHub Bot Created on: 05/Feb/21 14:20 Start Date: 05/Feb/21 14:20 Worklog Time Spent: 10m Work Description: michaelpearce-gain commented on a change in pull request #18: URL: https://github.com/apache/activemq-nms-api/pull/18#discussion_r570999228 ## File path: src/nms-api/INMSContext.cs ## @@ -117,11 +188,21 @@ public interface INMSContext : IDisposable, IStartable, IStoppable /// Creates a temporary queue /// ITemporaryQueue CreateTemporaryQueue(); + +/// +/// Creates a temporary queue +/// +Task CreateTemporaryQueueAsync(); Review comment: How about GetQueue and GetTopic 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548655) Time Spent: 10h 20m (was: 10h 10m) > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 10h 20m > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3074) Add ActiveMQServerControl#createBridge() method variant which accepts the callTimeout attribute
[
https://issues.apache.org/jira/browse/ARTEMIS-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-3074.
-
Fix Version/s: 2.17.0
Resolution: Fixed
> Add ActiveMQServerControl#createBridge() method variant which accepts the
> callTimeout attribute
> ---
>
> Key: ARTEMIS-3074
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3074
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.16.0
>Reporter: Tomas Hofman
>Priority: Major
> Fix For: 2.17.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Currently there are four variants of the
> {{ActiveMQServerControl#createBridge()}} method, none of which accepts the
> {{callTimeout}} attribute of the core bridge.
> The {{callTimeout}} attribute sets a call timeout for blocking calls to the
> server. Typically a bridge works in a non-blocking manner, but in some cases
> customers use configurations where calls do block.
> It would still be possible to set call timeout without this change using
> lower level API ({{ActiveMQServer#deployBridge()}}), but it would require
> duplicating some code which is already there in {{ActiveMQServerControl}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548653=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548653
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 14:14
Start Date: 05/Feb/21 14:14
Worklog Time Spent: 10m
Work Description: gtully commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r570995173
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,11 +17,31 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.ServiceLoader;
+import java.util.stream.Stream;
+
public class MechanismFinder {
- public static String[] KNOWN_MECHANISMS = new String[]{PlainSASL.NAME,
AnonymousServerSASL.NAME};
+ private static final String[] DEFAULT_MECHANISMS = new String[]
{PlainSASL.NAME, AnonymousServerSASL.NAME};
+
+ private static final Map FACTORY_MAP = new
HashMap<>();
+
+ static {
+ ServiceLoader serviceLoader =
+ ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
+ for (ServerSASLFactory factory : serviceLoader) {
+ FACTORY_MAP.put(factory.getMechanism(), factory);
+ }
+ }
public static String[] getKnownMechanisms() {
- return KNOWN_MECHANISMS;
+ return Stream.concat(Arrays.stream(DEFAULT_MECHANISMS),
FACTORY_MAP.keySet().stream()).toArray(String[]::new);
Review comment:
maybe use "position", follow java.security.Security#insertProviderAt - a
provider at an existing position cannot be overridden. In this way it can be
clear what the default order is. duplicates need to figure out where they fit
in the ordered list to be effective.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548653)
Time Spent: 1.5h (was: 1h 20m)
> Generic integration with SASL Frameworks
>
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Clebert Suconic
>Priority: Critical
> Fix For: unscheduled
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should
> investigate if there is any interest extending SASL into any other protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3092) Inconsistent JDBC config logging
[
https://issues.apache.org/jira/browse/ARTEMIS-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-3092.
-
Fix Version/s: 2.17.0
Resolution: Fixed
> Inconsistent JDBC config logging
>
>
> Key: ARTEMIS-3092
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3092
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.17.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When starting the broker with the new JDBC connection pooling feature, we
> have an incorrect configuration log:
> {code}
> 2021-01-29 19:34:58,057 INFO
> [org.apache.activemq.artemis.jdbc.store.drivers.JDBCDataSourceUtils]
> Initialising JDBC data source: org.apache.commons.dbcp2.BasicDataSource
> {password=ACTIVE_MQ, maxTotal=-1,
> driverClassName=oracle.jdbc.driver.OracleDriver, poolPreparedStatements=true,
> url=jdbc:oracle:thin:@(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(ENABLE=BROKEN)(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=AMQDMSTA1S)))(DESCRIPTION=(ENABLE=BROKEN)(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=xxx,
> username=ACTIVE_MQ}
> 2021-01-29 19:34:59,254 INFO [org.apache.activemq.artemis.core.server]
> AMQ221000: live Message Broker is starting with configuration Broker
> Configuration
> (clustered=true,jdbcDriverClassName=org.apache.derby.jdbc.EmbeddedDriver,jdbcConnectionUrl=null,messageTableName=MESSAGES,bindingsTableName=BINDINGS,largeMessageTableName=LARGE_MESSAGES,pageStoreTableName=PAGE_STORE,)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3096) Bridge config using wrong default confirmation window size
[
https://issues.apache.org/jira/browse/ARTEMIS-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-3096.
-
Fix Version/s: 2.17.0
Resolution: Fixed
> Bridge config using wrong default confirmation window size
> --
>
> Key: ARTEMIS-3096
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3096
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.17.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Defining and deploying a simple core bridge results in an exception. For
> example:
> {code:java}
> server.deployBridge(new BridgeConfiguration()
> .setName("myBridge")
> .setQueueName("myQueue")
> .setForwardingAddress("myFowardingAddress")
> .setStaticConnectors(List.of("in-vm")));
> {code}
> Results in this:
> {noformat}
> [Thread-0
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1fb19a0)]
> 12:08:53,386 WARN [org.apache.activemq.artemis.core.server] AMQ222099:
> Bridge BridgeImpl@d3cc2c1 [name=myBridge, queue=QueueImpl[name=myQueue,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=09d8c4ef-6714-11eb-b80b-5c80b6f32172],
> temp=false]@3b365709 targetConnector=ServerLocatorImpl (identity=Bridge
> myBridge)
> [initialConnectors=[TransportConfiguration(name=09bc3c3e-6714-11eb-b80b-5c80b6f32172,
>
> factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
> ?serverId=0], discoveryGroupConfiguration=null]] is unable to connect to
> destination. It will be disabled.: java.lang.IllegalStateException: You can't
> set confirmationHandler on a connection with confirmation-window-size < 0.
> Look at the documentation for more information.
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.setCommandConfirmationHandler(ChannelImpl.java:592)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.setHandlers(ActiveMQSessionContext.java:194)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.setSendAcknowledgementHandler(ActiveMQSessionContext.java:275)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.setSendAcknowledgementHandler(ClientSessionImpl.java:1364)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.setSendAcknowledgementHandler(ClientSessionImpl.java:62)
> at
> org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl.connect(BridgeImpl.java:1020)
> at
> org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl$ConnectRunnable.run(BridgeImpl.java:1189)
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> {noformat}
> The only way to work around this is to manually set the confirmation window
> size on the bridge configuration.
> Bridges deployed via {{broker.xml}} don't suffer from this problem because
> the confirmation window size is set to the proper default value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279712#comment-17279712
]
Luís Alves commented on ARTEMIS-2886:
-
{quote}Where is the loop here, does a client in a loop doing send get a
security exception as a response, but the connection stays valid?text{quote}
exactly. Client keep get not authorized when if fact he is not even
"authenticated". Trace:
{noformat}
javax.jms.JMSSecurityException: AMQ229032: User: does not have
permission='SEND' on address business-events.eu.jms-java-app-demo.ms.v1.a
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:540)
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:434)
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.simpleCommit(ActiveMQSessionContext.java:452)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:964)
at
org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:937)
at
org.apache.activemq.artemis.jms.client.ActiveMQSession.commit(ActiveMQSession.java:289)
at
org.messaginghub.pooled.jms.JmsPoolSession.commit(JmsPoolSession.java:266)
...
{noformat}
You really described well the whole problem and as you mention it can happen on
LDAP as well.
I would propose something like this:
{code:java}
final Boolean validated;
if (securityManager instanceof ActiveMQSecurityManager5) {
Subject subject = getSubjectForAuthorization(session,
((ActiveMQSecurityManager5) securityManager));
if(isNull(subject)){
//thrash the connection as user is not authenticated anymore.
}
validated = ((ActiveMQSecurityManager5)
securityManager).authorize(subject, roles, checkType, fqqn != null ?
fqqn.toString() : bareAddress.toString());
}
{code}
Not sure how to properly trash the connection. I'm currently trying to find out
if sending some JMSRuntimeException will do the trick, as I can send it myself
from the authenticate method. Although, it would be nice that this is done on
SecurityStoreImpl class.
Regarding the test case, I don't have one, sorry. Also, don't have enough
knowledge to setup on quickly.
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?focusedWorklogId=548651=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548651 ] ASF GitHub Bot logged work on AMQNET-637: - Author: ASF GitHub Bot Created on: 05/Feb/21 14:08 Start Date: 05/Feb/21 14:08 Worklog Time Spent: 10m Work Description: lukeabsent opened a new pull request #18: URL: https://github.com/apache/activemq-nms-api/pull/18 Work in progress 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548651) Time Spent: 10h 10m (was: 10h) > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 10h 10m > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548649=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548649
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 14:06
Start Date: 05/Feb/21 14:06
Worklog Time Spent: 10m
Work Description: gtully commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r570989952
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,11 +17,31 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.ServiceLoader;
+import java.util.stream.Stream;
+
public class MechanismFinder {
- public static String[] KNOWN_MECHANISMS = new String[]{PlainSASL.NAME,
AnonymousServerSASL.NAME};
+ private static final String[] DEFAULT_MECHANISMS = new String[]
{PlainSASL.NAME, AnonymousServerSASL.NAME};
+
+ private static final Map FACTORY_MAP = new
HashMap<>();
+
+ static {
+ ServiceLoader serviceLoader =
+ ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
+ for (ServerSASLFactory factory : serviceLoader) {
+ FACTORY_MAP.put(factory.getMechanism(), factory);
+ }
+ }
public static String[] getKnownMechanisms() {
- return KNOWN_MECHANISMS;
+ return Stream.concat(Arrays.stream(DEFAULT_MECHANISMS),
FACTORY_MAP.keySet().stream()).toArray(String[]::new);
Review comment:
With the precedence feature, having the existing mechanisms use this
loader makes sense. The actual published mechanisms on the amqp acceptor can be
explicitly configured on amqp protocol manager via the saslMechanisms property.
That separates the loading from the use, but the defaults should have a
sensible order as @gemmellr points out. I think there are existing tests that
verify that.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548649)
Time Spent: 1h 20m (was: 1h 10m)
> Generic integration with SASL Frameworks
>
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Clebert Suconic
>Priority: Critical
> Fix For: unscheduled
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should
> investigate if there is any interest extending SASL into any other protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548646=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548646
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 14:00
Start Date: 05/Feb/21 14:00
Worklog Time Spent: 10m
Work Description: laeubi commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r570986144
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,11 +17,31 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.ServiceLoader;
+import java.util.stream.Stream;
+
public class MechanismFinder {
- public static String[] KNOWN_MECHANISMS = new String[]{PlainSASL.NAME,
AnonymousServerSASL.NAME};
+ private static final String[] DEFAULT_MECHANISMS = new String[]
{PlainSASL.NAME, AnonymousServerSASL.NAME};
+
+ private static final Map FACTORY_MAP = new
HashMap<>();
+
+ static {
+ ServiceLoader serviceLoader =
+ ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
+ for (ServerSASLFactory factory : serviceLoader) {
+ FACTORY_MAP.put(factory.getMechanism(), factory);
+ }
+ }
public static String[] getKnownMechanisms() {
- return KNOWN_MECHANISMS;
+ return Stream.concat(Arrays.stream(DEFAULT_MECHANISMS),
FACTORY_MAP.keySet().stream()).toArray(String[]::new);
Review comment:
Thanks for the advice, I have added now a "precedence" that is used to
maintains it ordering. In case of duplicate mechanism registered the one with
the highest precedence wins.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548646)
Time Spent: 1h 10m (was: 1h)
> Generic integration with SASL Frameworks
>
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Clebert Suconic
>Priority: Critical
> Fix For: unscheduled
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should
> investigate if there is any interest extending SASL into any other protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[
https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548630=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548630
]
ASF GitHub Bot logged work on ARTEMIS-33:
-
Author: ASF GitHub Bot
Created on: 05/Feb/21 12:45
Start Date: 05/Feb/21 12:45
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3432:
URL: https://github.com/apache/activemq-artemis/pull/3432#discussion_r570898820
##
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/sasl/MechanismFinder.java
##
@@ -17,11 +17,31 @@
package org.apache.activemq.artemis.protocol.amqp.sasl;
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.ServiceLoader;
+import java.util.stream.Stream;
+
public class MechanismFinder {
- public static String[] KNOWN_MECHANISMS = new String[]{PlainSASL.NAME,
AnonymousServerSASL.NAME};
+ private static final String[] DEFAULT_MECHANISMS = new String[]
{PlainSASL.NAME, AnonymousServerSASL.NAME};
+
+ private static final Map FACTORY_MAP = new
HashMap<>();
+
+ static {
+ ServiceLoader serviceLoader =
+ ServiceLoader.load(ServerSASLFactory.class,
MechanismFinder.class.getClassLoader());
+ for (ServerSASLFactory factory : serviceLoader) {
+ FACTORY_MAP.put(factory.getMechanism(), factory);
+ }
+ }
public static String[] getKnownMechanisms() {
- return KNOWN_MECHANISMS;
+ return Stream.concat(Arrays.stream(DEFAULT_MECHANISMS),
FACTORY_MAP.keySet().stream()).toArray(String[]::new);
Review comment:
The server is meant to announce them in descending order of preference,
and little should ever come after ANONYMOUS, so this seems questionable. So
would just dumping them at the front, though possibly less so.
It should perhaps also be guarded that its not a duplicate, avoiding dup
mech announcements and perhaps also alert that a loaded mechanism wont be used
should it already be known/handled.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548630)
Time Spent: 1h (was: 50m)
> Generic integration with SASL Frameworks
>
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Clebert Suconic
>Priority: Critical
> Fix For: unscheduled
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should
> investigate if there is any interest extending SASL into any other protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548617=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548617 ] ASF GitHub Bot logged work on ARTEMIS-33: - Author: ASF GitHub Bot Created on: 05/Feb/21 12:23 Start Date: 05/Feb/21 12:23 Worklog Time Spent: 10m Work Description: laeubi commented on pull request #3432: URL: https://github.com/apache/activemq-artemis/pull/3432#issuecomment-774001534 @gtully what do you think about transforming the both defaults (PLAIN, ANONYMOUS) to the new way of providing a SASL-Mechanism? Would this suffice? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548617) Time Spent: 50m (was: 40m) > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Clebert Suconic >Priority: Critical > Fix For: unscheduled > > Time Spent: 50m > Remaining Estimate: 0h > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548601=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548601 ] ASF GitHub Bot logged work on ARTEMIS-33: - Author: ASF GitHub Bot Created on: 05/Feb/21 11:55 Start Date: 05/Feb/21 11:55 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3432: URL: https://github.com/apache/activemq-artemis/pull/3432#issuecomment-773988304 It can be any dummy SASL thing, just that it completes the round trip from being requested by a client to being found and loaded by the server. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548601) Time Spent: 40m (was: 0.5h) > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Clebert Suconic >Priority: Critical > Fix For: unscheduled > > Time Spent: 40m > Remaining Estimate: 0h > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279637#comment-17279637
]
Gary Tully commented on ARTEMIS-2886:
-
Where is the loop here, does a client in a loop doing send get a security
exception as a response, but the connection stays valid?
I don't think your use case is unique to OpenID, the cached ldap jaas login
module can find that permissions have been removed from ldap at runtime and
that authorization has been removed. Once the cache expires and jaas is again
asked, it too will return a null subject i think and subsequent operations will
result in exceptions in the same way. I don't know how it will behave if a user
is no longer valid.
typically a security exception on initial connection, a failure to
authenticate, will cause the connection to be rejected, the connection to
close. But security exceptions are expected at runtime if you have access to
some resources and not others and are not aware of that. If permissions change
at runtime, some variation here is ok.
If however, a users is no longer able to authenticate (in your case, the token
has expired and cannot be renewed, then we need to drop the connection.
*_as a straw man design:_*
We may have to change the use of Subject in the code, a valid subject is non
null and has a valid artemis user principal. We need to check for the presence
of the user principal. That can indicate if the authentication is still valid.
If we can proceed with authorization checks.
At runtime, we may find that the non null subject becomes invalid b/c the
artemis principal is removed and that should cause any authorisation attempt to
fail and the connection to error out or be forcefully closed.
I think we need to do something like this.
Do you have any tests that can demonstrate the current problem?
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548582=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548582 ] ASF GitHub Bot logged work on ARTEMIS-33: - Author: ASF GitHub Bot Created on: 05/Feb/21 10:49 Start Date: 05/Feb/21 10:49 Worklog Time Spent: 10m Work Description: laeubi commented on pull request #3432: URL: https://github.com/apache/activemq-artemis/pull/3432#issuecomment-773956194 I have prepared [an example ](https://github.com/laeubi/scram-sasl/commit/973a0a2b1c495a30bc4d6720ae9b735f5467525f)that builds up this new feature to support SASL-SCRAM. Would be really helpful if this could go into the release next week. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548582) Time Spent: 0.5h (was: 20m) > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Clebert Suconic >Priority: Critical > Fix For: unscheduled > > Time Spent: 0.5h > Remaining Estimate: 0h > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2984) Compressed large messages can leak native resources
[ https://issues.apache.org/jira/browse/ARTEMIS-2984?focusedWorklogId=548506=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548506 ] ASF GitHub Bot logged work on ARTEMIS-2984: --- Author: ASF GitHub Bot Created on: 05/Feb/21 10:28 Start Date: 05/Feb/21 10:28 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3334: URL: https://github.com/apache/activemq-artemis/pull/3334#issuecomment-773587875 @franz1981 what's the status on this PR? is this ready to merge? I saw briefly one assert (that I added a comment) that I wasn't sure at a first look. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548506) Time Spent: 4h 50m (was: 4h 40m) > Compressed large messages can leak native resources > --- > > Key: ARTEMIS-2984 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2984 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 50m > Remaining Estimate: 0h > > Compressed large messages use native resources in the form of Inflater and > Deflater and should release them in a timely manner (instead of relying on > finalization) to save OOM to happen (of direct memory, to be precise). > This issue has the chance to simplify large message controllers, because much > of the existing code on controllers (including compressed one) isn't needed > at runtime, but just for testing purposes and a proper fix can move dead code > there too, saving leaky behavior to be maintained. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3045) ReplicationManager can batch sent replicated packets
[ https://issues.apache.org/jira/browse/ARTEMIS-3045?focusedWorklogId=548473=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548473 ] ASF GitHub Bot logged work on ARTEMIS-3045: --- Author: ASF GitHub Bot Created on: 05/Feb/21 10:25 Start Date: 05/Feb/21 10:25 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3392: URL: https://github.com/apache/activemq-artemis/pull/3392#issuecomment-773873107 @clebertsuconic @michaelandrepearce Plese don't merge it yet: I see that if I use the Netty connection event loop used for the replication I'm getting a much better performance, both troughput and latency-wise ie ``` ** RUN 4EndToEnd Throughput: 29681 ops/sec ** EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS mean 1114.38 min 174.08 50.00% 987.14 90.00% 1548.29 99.00% 3702.78 99.90% 7110.66 99.99%11599.87 max 15007.74 count 32 ``` But it means that I should handle network backpressure differently 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548473) Time Spent: 4h 10m (was: 4h) > ReplicationManager can batch sent replicated packets > > > Key: ARTEMIS-3045 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3045 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3096) Bridge config using wrong default confirmation window size
[
https://issues.apache.org/jira/browse/ARTEMIS-3096?focusedWorklogId=548348=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548348
]
ASF GitHub Bot logged work on ARTEMIS-3096:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 10:12
Start Date: 05/Feb/21 10:12
Worklog Time Spent: 10m
Work Description: asfgit merged pull request #3430:
URL: https://github.com/apache/activemq-artemis/pull/3430
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548348)
Time Spent: 0.5h (was: 20m)
> Bridge config using wrong default confirmation window size
> --
>
> Key: ARTEMIS-3096
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3096
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Defining and deploying a simple core bridge results in an exception. For
> example:
> {code:java}
> server.deployBridge(new BridgeConfiguration()
> .setName("myBridge")
> .setQueueName("myQueue")
> .setForwardingAddress("myFowardingAddress")
> .setStaticConnectors(List.of("in-vm")));
> {code}
> Results in this:
> {noformat}
> [Thread-0
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1fb19a0)]
> 12:08:53,386 WARN [org.apache.activemq.artemis.core.server] AMQ222099:
> Bridge BridgeImpl@d3cc2c1 [name=myBridge, queue=QueueImpl[name=myQueue,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=09d8c4ef-6714-11eb-b80b-5c80b6f32172],
> temp=false]@3b365709 targetConnector=ServerLocatorImpl (identity=Bridge
> myBridge)
> [initialConnectors=[TransportConfiguration(name=09bc3c3e-6714-11eb-b80b-5c80b6f32172,
>
> factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
> ?serverId=0], discoveryGroupConfiguration=null]] is unable to connect to
> destination. It will be disabled.: java.lang.IllegalStateException: You can't
> set confirmationHandler on a connection with confirmation-window-size < 0.
> Look at the documentation for more information.
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.setCommandConfirmationHandler(ChannelImpl.java:592)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.setHandlers(ActiveMQSessionContext.java:194)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.setSendAcknowledgementHandler(ActiveMQSessionContext.java:275)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.setSendAcknowledgementHandler(ClientSessionImpl.java:1364)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.setSendAcknowledgementHandler(ClientSessionImpl.java:62)
> at
> org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl.connect(BridgeImpl.java:1020)
> at
> org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl$ConnectRunnable.run(BridgeImpl.java:1189)
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> {noformat}
> The only way to work around this is to manually set the confirmation window
> size on the bridge configuration.
> Bridges deployed via {{broker.xml}} don't suffer from this problem because
> the confirmation window size is set to the proper default value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3096) Bridge config using wrong default confirmation window size
[
https://issues.apache.org/jira/browse/ARTEMIS-3096?focusedWorklogId=548354=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548354
]
ASF GitHub Bot logged work on ARTEMIS-3096:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 10:13
Start Date: 05/Feb/21 10:13
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request #3430:
URL: https://github.com/apache/activemq-artemis/pull/3430
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548354)
Time Spent: 40m (was: 0.5h)
> Bridge config using wrong default confirmation window size
> --
>
> Key: ARTEMIS-3096
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3096
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Defining and deploying a simple core bridge results in an exception. For
> example:
> {code:java}
> server.deployBridge(new BridgeConfiguration()
> .setName("myBridge")
> .setQueueName("myQueue")
> .setForwardingAddress("myFowardingAddress")
> .setStaticConnectors(List.of("in-vm")));
> {code}
> Results in this:
> {noformat}
> [Thread-0
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1fb19a0)]
> 12:08:53,386 WARN [org.apache.activemq.artemis.core.server] AMQ222099:
> Bridge BridgeImpl@d3cc2c1 [name=myBridge, queue=QueueImpl[name=myQueue,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=09d8c4ef-6714-11eb-b80b-5c80b6f32172],
> temp=false]@3b365709 targetConnector=ServerLocatorImpl (identity=Bridge
> myBridge)
> [initialConnectors=[TransportConfiguration(name=09bc3c3e-6714-11eb-b80b-5c80b6f32172,
>
> factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory)
> ?serverId=0], discoveryGroupConfiguration=null]] is unable to connect to
> destination. It will be disabled.: java.lang.IllegalStateException: You can't
> set confirmationHandler on a connection with confirmation-window-size < 0.
> Look at the documentation for more information.
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.setCommandConfirmationHandler(ChannelImpl.java:592)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.setHandlers(ActiveMQSessionContext.java:194)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.setSendAcknowledgementHandler(ActiveMQSessionContext.java:275)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.setSendAcknowledgementHandler(ClientSessionImpl.java:1364)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.setSendAcknowledgementHandler(ClientSessionImpl.java:62)
> at
> org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl.connect(BridgeImpl.java:1020)
> at
> org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl$ConnectRunnable.run(BridgeImpl.java:1189)
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> {noformat}
> The only way to work around this is to manually set the confirmation window
> size on the bridge configuration.
> Bridges deployed via {{broker.xml}} don't suffer from this problem because
> the confirmation window size is set to the proper default value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3092) Inconsistent JDBC config logging
[
https://issues.apache.org/jira/browse/ARTEMIS-3092?focusedWorklogId=548379=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548379
]
ASF GitHub Bot logged work on ARTEMIS-3092:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 10:15
Start Date: 05/Feb/21 10:15
Worklog Time Spent: 10m
Work Description: asfgit closed pull request #3427:
URL: https://github.com/apache/activemq-artemis/pull/3427
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548379)
Time Spent: 40m (was: 0.5h)
> Inconsistent JDBC config logging
>
>
> Key: ARTEMIS-3092
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3092
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When starting the broker with the new JDBC connection pooling feature, we
> have an incorrect configuration log:
> {code}
> 2021-01-29 19:34:58,057 INFO
> [org.apache.activemq.artemis.jdbc.store.drivers.JDBCDataSourceUtils]
> Initialising JDBC data source: org.apache.commons.dbcp2.BasicDataSource
> {password=ACTIVE_MQ, maxTotal=-1,
> driverClassName=oracle.jdbc.driver.OracleDriver, poolPreparedStatements=true,
> url=jdbc:oracle:thin:@(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(ENABLE=BROKEN)(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=AMQDMSTA1S)))(DESCRIPTION=(ENABLE=BROKEN)(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=xxx,
> username=ACTIVE_MQ}
> 2021-01-29 19:34:59,254 INFO [org.apache.activemq.artemis.core.server]
> AMQ221000: live Message Broker is starting with configuration Broker
> Configuration
> (clustered=true,jdbcDriverClassName=org.apache.derby.jdbc.EmbeddedDriver,jdbcConnectionUrl=null,messageTableName=MESSAGES,bindingsTableName=BINDINGS,largeMessageTableName=LARGE_MESSAGES,pageStoreTableName=PAGE_STORE,)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2984) Compressed large messages can leak native resources
[
https://issues.apache.org/jira/browse/ARTEMIS-2984?focusedWorklogId=548309=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548309
]
ASF GitHub Bot logged work on ARTEMIS-2984:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 10:09
Start Date: 05/Feb/21 10:09
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3334:
URL: https://github.com/apache/activemq-artemis/pull/3334#discussion_r570526133
##
File path:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientProducerImpl.java
##
@@ -410,108 +410,117 @@ private void largeMessageSendBuffered(final boolean
sendBlocking,
/**
* @param sendBlocking
* @param msgI
-* @param inputStreamParameter
+* @param inputStream
* @param credits
* @throws ActiveMQException
*/
private void largeMessageSendStreamed(final boolean sendBlocking,
final ICoreMessage msgI,
- final InputStream
inputStreamParameter,
+ final InputStream inputStream,
final ClientProducerCredits credits,
SendAcknowledgementHandler handler)
throws ActiveMQException {
- boolean lastPacket = false;
+ final DeflaterReader deflaterReader = session.isCompressLargeMessages()
? new DeflaterReader(inputStream) : null;
- InputStream input = inputStreamParameter;
+ try (InputStream input = session.isCompressLargeMessages() ?
deflaterReader : inputStream) {
- // We won't know the real size of the message since we are compressing
while reading the streaming.
- // This counter will be passed to the deflater to be updated for every
byte read
- AtomicLong messageSize = new AtomicLong();
-
- DeflaterReader deflaterReader = null;
-
- if (session.isCompressLargeMessages()) {
- msgI.putBooleanProperty(Message.HDR_LARGE_COMPRESSED, true);
- deflaterReader = new DeflaterReader(inputStreamParameter,
messageSize);
- input = deflaterReader;
- }
-
- long totalSize = 0;
-
- boolean headerSent = false;
-
- int reconnectID = sessionContext.getReconnectID();
- while (!lastPacket) {
- byte[] buff = new byte[minLargeMessageSize];
-
- int pos = 0;
-
- do {
-int numberOfBytesRead;
-
-int wanted = minLargeMessageSize - pos;
-
-try {
- numberOfBytesRead = input.read(buff, pos, wanted);
-} catch (IOException e) {
- throw ActiveMQClientMessageBundle.BUNDLE.errorReadingBody(e);
-}
-
-if (numberOfBytesRead == -1) {
- lastPacket = true;
-
- break;
-}
-
-pos += numberOfBytesRead;
+ if (session.isCompressLargeMessages()) {
+msgI.putBooleanProperty(Message.HDR_LARGE_COMPRESSED, true);
}
- while (pos < minLargeMessageSize);
- totalSize += pos;
+ long totalBytesRead = 0;
- if (lastPacket) {
-if (!session.isCompressLargeMessages()) {
- messageSize.set(totalSize);
-}
+ boolean headerSent = false;
+
+ int reconnectID = sessionContext.getReconnectID();
+ while (true) {
+final byte[] scratchBuffer = new byte[minLargeMessageSize];
-// This is replacing the last packet by a smaller packet
-byte[] buff2 = new byte[pos];
+final int result = readLargeMessageChunk(input, scratchBuffer,
minLargeMessageSize);
-System.arraycopy(buff, 0, buff2, 0, pos);
+final int bytesRead = bytesRead(result);
-buff = buff2;
+totalBytesRead += bytesRead;
-// This is the case where the message is being converted as a
regular message
-if (!headerSent && session.isCompressLargeMessages() &&
buff2.length < minLargeMessageSize) {
- msgI.getBodyBuffer().resetReaderIndex();
- msgI.getBodyBuffer().resetWriterIndex();
- msgI.putLongProperty(Message.HDR_LARGE_BODY_SIZE,
deflaterReader.getTotalSize());
+final boolean lastPacket = isLargeMessageLastPacket(result);
- msgI.getBodyBuffer().writeBytes(buff, 0, pos);
- sendRegularMessage(msgI.getAddressSimpleString(), msgI,
sendBlocking, credits, handler);
- return;
-} else {
+if (lastPacket) {
+ // This is the case where the message is being converted as a
regular message
+ if (!headerSent && session.isCompressLargeMessages() &&
bytesRead < minLargeMessageSize) {
+ assert bytesRead
[jira] [Work logged] (ARTEMIS-33) Generic integration with SASL Frameworks
[ https://issues.apache.org/jira/browse/ARTEMIS-33?focusedWorklogId=548294=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548294 ] ASF GitHub Bot logged work on ARTEMIS-33: - Author: ASF GitHub Bot Created on: 05/Feb/21 10:07 Start Date: 05/Feb/21 10:07 Worklog Time Spent: 10m Work Description: laeubi opened a new pull request #3432: URL: https://github.com/apache/activemq-artemis/pull/3432 This adds the opportunity to register new SASL schemes via the default java service-loader mechanism. Implementors have to provide an implementation of the ServerSASLFactory that is responsible for providing instances of the actual scheme. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548294) Time Spent: 20m (was: 10m) > Generic integration with SASL Frameworks > > > Key: ARTEMIS-33 > URL: https://issues.apache.org/jira/browse/ARTEMIS-33 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 1.0.0 >Reporter: Clebert Suconic >Priority: Critical > Fix For: unscheduled > > Time Spent: 20m > Remaining Estimate: 0h > > Right now we are bound to User/Password or anonymous on SASL. > We should use some framework that would allow SASL integration with a bigger > number of possibilities. > We should investigate options from the JDK for this... or if there is any > other framework available. > I believe this only affects AMQP, but as part of this issue we should > investigate if there is any interest extending SASL into any other protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3100) I failed to configure SSL in combination with HA Failover
Dominik Figl created ARTEMIS-3100: - Summary: I failed to configure SSL in combination with HA Failover Key: ARTEMIS-3100 URL: https://issues.apache.org/jira/browse/ARTEMIS-3100 Project: ActiveMQ Artemis Issue Type: Wish Affects Versions: 2.16.0 Reporter: Dominik Figl I failed to configure Artemis with one-way SSL in combination with HA Failover. Can anybody point out a working example to me? (I'm pretty new to that topic :) ) I also failed to get access to the slack channel :\ My Goal: 2 Artemis Instances on CentOs Servers (one live and one backup server) with Server Side Certificate to enable the clients to encrypt the traffic. No Client side certs are needed. My current configurate attempt: LIVE: tcp://0.0.0.0:61619?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;sslProvider=OPENSSL;keyStorePath=activemq.example.keystore;keyStorePassword=activemqexample;enabledProtocols=TLSv1,TLSv1.1,TLSv1.2;needClientAuth=false;verifyHost=false;trustAll=true tcp://vrz8576t:61619 tcp://kai8576t:61619 artemis ON_DEMAND 0 artemis-slave-connector BACKUP: tcp://0.0.0.0:61619?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;sslProvider=OPENSSL;keyStorePath=activemq.example.keystore;keyStorePassword=activemqexample;enabledProtocols=TLSv1,TLSv1.1,TLSv1.2;needClientAuth=false;verifyHost=false;trustAll=true tcp://kai8576t:61619 tcp://vrz8576t:61619 artemis ON_DEMAND 0 artemis-master-connector Certificate generation: keytool -genkey -keystore activemq.example.keystore -storepass activemqexample -keypass activemqexample -dname "CN=ActiveMQ Artemis Server, OU=Artemis, O=ActiveMQ, L=AMQ, S=AMQ, C=AMQ" -keyalg RSA keytool -export -keystore activemq.example.keystore -file server-side-cert.cer -storepass activemqexample keytool -import -keystore activemq.example.truststore -file server-side-cert.cer -storepass activemqexample -keypass activemqexample -noprompt BR Dominik -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3074) Add ActiveMQServerControl#createBridge() method variant which accepts the callTimeout attribute
[
https://issues.apache.org/jira/browse/ARTEMIS-3074?focusedWorklogId=548142=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548142
]
ASF GitHub Bot logged work on ARTEMIS-3074:
---
Author: ASF GitHub Bot
Created on: 05/Feb/21 09:49
Start Date: 05/Feb/21 09:49
Worklog Time Spent: 10m
Work Description: rvais commented on pull request #3412:
URL: https://github.com/apache/activemq-artemis/pull/3412#issuecomment-773280008
I reviewed this PR as well. The tests which are included should be should be
sufficient for the purpose. Feel free to reopen this for future Artemis version.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 548142)
Time Spent: 4.5h (was: 4h 20m)
> Add ActiveMQServerControl#createBridge() method variant which accepts the
> callTimeout attribute
> ---
>
> Key: ARTEMIS-3074
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3074
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.16.0
>Reporter: Tomas Hofman
>Priority: Major
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Currently there are four variants of the
> {{ActiveMQServerControl#createBridge()}} method, none of which accepts the
> {{callTimeout}} attribute of the core bridge.
> The {{callTimeout}} attribute sets a call timeout for blocking calls to the
> server. Typically a bridge works in a non-blocking manner, but in some cases
> customers use configurations where calls do block.
> It would still be possible to set call timeout without this change using
> lower level API ({{ActiveMQServer#deployBridge()}}), but it would require
> duplicating some code which is already there in {{ActiveMQServerControl}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3050) Reduce PagedReferenceImpl memory footprint
[ https://issues.apache.org/jira/browse/ARTEMIS-3050?focusedWorklogId=548162=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548162 ] ASF GitHub Bot logged work on ARTEMIS-3050: --- Author: ASF GitHub Bot Created on: 05/Feb/21 09:51 Start Date: 05/Feb/21 09:51 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3397: URL: https://github.com/apache/activemq-artemis/pull/3397#issuecomment-773588200 postponing after the next release... as discussed. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548162) Time Spent: 1h 50m (was: 1h 40m) > Reduce PagedReferenceImpl memory footprint > -- > > Key: ARTEMIS-3050 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3050 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Trivial > Time Spent: 1h 50m > Remaining Estimate: 0h > > PagedReferenceImpl is never being used as QueueImpl node, hence it doesn't > make sense for it to extends the node class, saving few bytes of memory > footprint eg a COOPS 64 bit JVM get 88 bytes vs 104 bytes -> ~18% saved > memory for each message ref with no semantic impacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3100) I failed to configure SSL in combination with HA Failover
[ https://issues.apache.org/jira/browse/ARTEMIS-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Figl updated ARTEMIS-3100: -- Description: I failed to configure Artemis with one-way SSL in combination with HA Failover. Can anybody point out a working example to me? (I'm pretty new to that topic :) ) I also failed to get access to the slack channel :\ My Goal: 2 Artemis Instances on CentOs Servers (one live and one backup server) with Server Side Certificate to enable the clients to encrypt the traffic. No Client side certs are needed. My current configurate attempt: LIVE: tcp://0.0.0.0:61619?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;keyStorePath=activemq.example.keystore;keyStorePassword=activemqexample;enabledProtocols=TLSv1,TLSv1.1,TLSv1.2;needClientAuth=false;verifyHost=false;trustAll=true tcp://vrz8576t:61619 tcp://kai8576t:61619 artemis ON_DEMAND 0 artemis-slave-connector BACKUP: tcp://0.0.0.0:61619?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;keyStorePath=activemq.example.keystore;keyStorePassword=activemqexample;enabledProtocols=TLSv1,TLSv1.1,TLSv1.2;needClientAuth=false;verifyHost=false;trustAll=true tcp://kai8576t:61619 tcp://vrz8576t:61619 artemis ON_DEMAND 0 artemis-master-connector Certificate generation: keytool -genkey -keystore activemq.example.keystore -storepass activemqexample -keypass activemqexample -dname "CN=ActiveMQ Artemis Server, OU=Artemis, O=ActiveMQ, L=AMQ, S=AMQ, C=AMQ" -keyalg RSA keytool -export -keystore activemq.example.keystore -file server-side-cert.cer -storepass activemqexample keytool -import -keystore activemq.example.truststore -file server-side-cert.cer -storepass activemqexample -keypass activemqexample -noprompt BR Dominik was: I failed to configure Artemis with one-way SSL in combination with HA Failover. Can anybody point out a working example to me? (I'm pretty new to that topic :) ) I also failed to get access to the slack channel :\ My Goal: 2 Artemis Instances on CentOs Servers (one live and one backup server) with Server Side Certificate to enable the clients to encrypt the traffic. No Client side certs are needed. My current configurate attempt: LIVE: tcp://0.0.0.0:61619?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;sslProvider=OPENSSL;keyStorePath=activemq.example.keystore;keyStorePassword=activemqexample;enabledProtocols=TLSv1,TLSv1.1,TLSv1.2;needClientAuth=false;verifyHost=false;trustAll=true tcp://vrz8576t:61619 tcp://kai8576t:61619 artemis ON_DEMAND 0 artemis-slave-connector BACKUP: tcp://0.0.0.0:61619?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;sslProvider=OPENSSL;keyStorePath=activemq.example.keystore;keyStorePassword=activemqexample;enabledProtocols=TLSv1,TLSv1.1,TLSv1.2;needClientAuth=false;verifyHost=false;trustAll=true tcp://kai8576t:61619 tcp://vrz8576t:61619 artemis ON_DEMAND 0 artemis-master-connector Certificate generation: keytool -genkey -keystore activemq.example.keystore -storepass activemqexample -keypass activemqexample -dname "CN=ActiveMQ Artemis Server, OU=Artemis, O=ActiveMQ, L=AMQ, S=AMQ, C=AMQ" -keyalg RSA keytool -export -keystore activemq.example.keystore -file server-side-cert.cer -storepass activemqexample keytool -import -keystore activemq.example.truststore -file server-side-cert.cer -storepass activemqexample -keypass activemqexample -noprompt BR Dominik > I failed to configure SSL in combination with HA Failover > - > > Key: ARTEMIS-3100 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3100 > Project: ActiveMQ Artemis > Issue Type: Wish >Affects Versions: 2.16.0 >Reporter: Dominik Figl >Priority: Trivial > > I failed to configure Artemis with one-way SSL in combination with HA > Failover. > Can anybody point out a
[jira] [Created] (ARTEMIS-3099) Bridge default producerWindowSize (-1) set at ActiveMQServer.deployBridge(BridgeConfiguration config) changes after broker reboot to 10485760
Mikhail Lukyanov created ARTEMIS-3099:
-
Summary: Bridge default producerWindowSize (-1) set at
ActiveMQServer.deployBridge(BridgeConfiguration config) changes after broker
reboot to 10485760
Key: ARTEMIS-3099
URL: https://issues.apache.org/jira/browse/ARTEMIS-3099
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.16.0
Reporter: Mikhail Lukyanov
Attachments: image-2021-02-05-11-11-30-420.png,
image-2021-02-05-11-22-14-901.png
I deploy bridge via ActiveMQServer.deployBridge(BridgeConfiguration config) like
{code:java}
server.deployBridge(new BridgeConfiguration()
.setName("myBridge")
.setQueueName("myQueue")
.setForwardingAddress("myFowardingAddress")
.setStaticConnectors(List.of("in-vm")));{code}
And default *producerWindowSize* set to -1
!image-2021-02-05-11-11-30-420.png!
Then I set this bridge to broker.xml like
{code:java}
myQueue
myFowardingAddress
in-vm
{code}
And after broker reboot, I get bridge with *producerWindowSize=10485760*
!image-2021-02-05-11-22-14-901.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3045) ReplicationManager can batch sent replicated packets
[ https://issues.apache.org/jira/browse/ARTEMIS-3045?focusedWorklogId=548082=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548082 ] ASF GitHub Bot logged work on ARTEMIS-3045: --- Author: ASF GitHub Bot Created on: 05/Feb/21 08:17 Start Date: 05/Feb/21 08:17 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3392: URL: https://github.com/apache/activemq-artemis/pull/3392#issuecomment-773873107 @clebertsuconic @michaelandrepearce Plese don't merge it yet: I see that if I use the Netty connection event loop used for the replication I'm getting a much better performance, both troughput and latency-wise ie ``` ** RUN 4EndToEnd Throughput: 29681 ops/sec ** EndToEnd SERVICE-TIME Latencies distribution in MICROSECONDS mean 1114.38 min 174.08 50.00% 987.14 90.00% 1548.29 99.00% 3702.78 99.90% 7110.66 99.99%11599.87 max 15007.74 count 32 ``` But it means that I should handle network backpressure differently 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 548082) Time Spent: 4h (was: 3h 50m) > ReplicationManager can batch sent replicated packets > > > Key: ARTEMIS-3045 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3045 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-8139) All About You Need To Know Applications of Micro Switches
basanti created AMQ-8139: Summary: All About You Need To Know Applications of Micro Switches Key: AMQ-8139 URL: https://issues.apache.org/jira/browse/AMQ-8139 Project: ActiveMQ Issue Type: Improvement Reporter: basanti Micro switches have numerous purposes. They can be used at properties and in plenty of industrial environments. For example, you'll find them in homes and the security and automation of buildings. In this text, we're going to dig deeper into the makes use of of these units. Automation and safety Today, micro switches are used for various purposes, similar to safety and automation. Given under are some of the widespread examples of the uses of those units. They may be found as push buttons, name points, and alarms. In an emergency, these buttons are pressed in order to activate an alarm in order that the concerned authorities can be alerted. They are additionally used as triggers to be able to prevent these units from being dismounted. Some common gadgets that have these models in them embody access control panels, card readers, and infrared detection alarm. The alarm goes off the second somebody tries to take away harm or dismount the unit. They are used in turning devices for safety cameras. The micro switch will get activated the moment the turning gadget goes beyond the purpose of motion. The thought is to make sure that the camera is not moved in a different course. The units are used for HVAC functions as well. In other phrases, these are used to detect adjustments in air stress. These items are used for access management as well. For example, they are used for electrical door locks. The objective of their installation is to detect the locking, unlocking, opening, and shutting of different types of doorways. Besides, micro switches are additionally put in to detect the opening of a roller door. They are part of circuit breakers to detect the status of turning on and off. Apart from this, these devices are used to detect the place of secure door locks. Micro switches can be found in timer controls. As quickly as time runs out, the switch is triggered. Home applications: Micro switches can be present in tons of house appliances. Some of these purposes are listed beneath: Washing machines: These tiny units are utilized in washing machines to turn them on and off. Plus, they detect switching power and the angle of filter and drums. When the door of the machine is opened or closed, these gadgets can detect it. Apart from this, micro switches can also detect the water level contained in the cabin. Refrigerators: these devices can also be used in fridges where they'll detect the position of the ice maker. Air conditioners: These units can detect the status of the door panels to find out if they're opened or closed. Apart from this, they are additionally used as a reset button on the air conditioner. Microwave ovens and rice cookers: In these appliances, micro switches can detect the standing of the duvet. Apart from this, in addition they operate as safety brief circuits. They also work as control panel switches. Long story quick, these are some widespread applications of micro switches in several settings. Hope this helps. If you might be in search of the most effective china micro switches producer, we advise that you simply take a look at [https://www.unionwellgermany.com/]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279478#comment-17279478
]
Luís Alves commented on ARTEMIS-2886:
-
I'm having a small issue with these blocks of code:
{code:java}
final Boolean validated;
if (securityManager instanceof ActiveMQSecurityManager5) {
Subject subject = getSubjectForAuthorization(session,
((ActiveMQSecurityManager5) securityManager));
validated = ((ActiveMQSecurityManager5)
securityManager).authorize(subject, roles, checkType, fqqn != null ?
fqqn.toString() : bareAddress.toString());
}
{code}
and
{code:java}
/**
* Get the cached Subject. If the Subject is not in the cache then
authenticate again to retrieve it.
*
* @param auth contains the authentication data
* @param securityManager used to authenticate the user if the Subject is
not in the cache
* @return the authenticated Subject with all associated role principals
*/
private Subject getSubjectForAuthorization(SecurityAuth auth,
ActiveMQSecurityManager5 securityManager) {
Pair cached =
authenticationCache.getIfPresent(createAuthenticationCacheKey(auth.getUsername(),
auth.getPassword(), auth.getRemotingConnection()));
/*
* We don't need to worry about the cached boolean being false as users
always have to
* successfully authenticate before requesting authorization for anything.
*/
if (cached == null) {
return securityManager.authenticate(auth.getUsername(),
auth.getPassword(), auth.getRemotingConnection(), auth.getSecurityDomain());
}
return cached.getB();
}
{code}
As I said I'm doing authN with OpenID Connect, and the Subject is a token that
eventually expires, so when the authenticate method is called it return null.
This doesn't cause the connection to drop so a new token can be generated.
Instead it just say the user is not authorized to do the operation and keeps
looping that.
The protocol used for communication wasn't design to send new tokens when they
expire, at least I couldn't figure out a way to do it. So after the connection
is established I cannot send a fresh token. I've seen the interceptors, but I
think we can only fiddle with the payload.
That said I think my tokens need to last more or even never expire. If they
don't expire I loose the concept of session, so it's my last option. Is there a
way to send some exception the cause the connection to be restarted? That way I
can make my connection to last 1hour or even 1 day and after that the
connection is trashed and on the new one I'll have a fresh token with the
proper authorization.
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
