[jira] [Created] (ARTEMIS-3194) Upgrade hawtio version to 2.13.1
Domenico Francesco Bruscino created ARTEMIS-3194: Summary: Upgrade hawtio version to 2.13.1 Key: ARTEMIS-3194 URL: https://issues.apache.org/jira/browse/ARTEMIS-3194 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Domenico Francesco Bruscino Assignee: Domenico Francesco Bruscino -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3194) Upgrade hawtio version to 2.13.1
[ https://issues.apache.org/jira/browse/ARTEMIS-3194?focusedWorklogId=569560&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569560 ] ASF GitHub Bot logged work on ARTEMIS-3194: --- Author: ASF GitHub Bot Created on: 22/Mar/21 07:31 Start Date: 22/Mar/21 07:31 Worklog Time Spent: 10m Work Description: brusdev opened a new pull request #3503: URL: https://github.com/apache/activemq-artemis/pull/3503 -- 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: 569560) Remaining Estimate: 0h Time Spent: 10m > Upgrade hawtio version to 2.13.1 > > > Key: ARTEMIS-3194 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3194 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3195) Filter empty items from listNetworkTopology
Domenico Francesco Bruscino created ARTEMIS-3195: Summary: Filter empty items from listNetworkTopology Key: ARTEMIS-3195 URL: https://issues.apache.org/jira/browse/ARTEMIS-3195 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Francesco Bruscino Assignee: Domenico Francesco Bruscino Sometimes the listNetworkTopology temporarily returns an empty item. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3195) Filter empty items from listNetworkTopology
[ https://issues.apache.org/jira/browse/ARTEMIS-3195?focusedWorklogId=569569&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569569 ] ASF GitHub Bot logged work on ARTEMIS-3195: --- Author: ASF GitHub Bot Created on: 22/Mar/21 08:08 Start Date: 22/Mar/21 08:08 Worklog Time Spent: 10m Work Description: brusdev opened a new pull request #3505: URL: https://github.com/apache/activemq-artemis/pull/3505 -- 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: 569569) Remaining Estimate: 0h Time Spent: 10m > Filter empty items from listNetworkTopology > --- > > Key: ARTEMIS-3195 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3195 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes the listNetworkTopology temporarily returns an empty item. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3190) AMQ222289: Did not route to any matching bindings on dead-letter-address DLQ and auto-create-dead-letter-resources is true
[
https://issues.apache.org/jira/browse/ARTEMIS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306085#comment-17306085
]
Gary Tully commented on ARTEMIS-3190:
-
With that dlq auto creation, it looks like the broker will be publishing to a
wildcard address, which is something that the wildcard binding manager does not
do.
That is a change that may be in play here, see:
https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/WildcardAddressManager.java#L49
> AMQ89: Did not route to any matching bindings on dead-letter-address DLQ
> and auto-create-dead-letter-resources is true
> --
>
> Key: ARTEMIS-3190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3190
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> When a client rollbacks the offered messages, the following error is visible:
> {noformat}
> WARN [org.apache.activemq.artemis.core.server] AMQ89: Did not route to
> any matching bindings on dead-letter-address DLQ and
> auto-create-dead-letter-resources is true; dropping message:
> Reference[375]:RELIABLE:AMQPStandardMessage( [durable=true, messageID=375,
> address=x1, size=189, applicationProperties={},
> properties=Properties{messageId=8bedcf71-a878-469f-9fdf-937c3dc44a02,
> userId=null, to='x1', subject='null', replyTo='null', correlationId=null,
> contentType=null, contentEncoding=null, absoluteExpiryTime=null,
> creationTime=Fri Mar 19 12:07:02 UTC 2021, groupId='null',
> groupSequence=null, replyToGroupId='null'}, extraProperties =
> TypedProperties[_AMQ_AD=x1]]
> {noformat}
> The original source code of Artemis says "this shouldn't happen, but in case
> it does it's better to log a message than just drop the message silently".
> And indeed the message is dropped.
> setup:
> * use a client that uses createSession(true, Session.CLIENT_ACKNOWLEDGE)
> * let the client always rollback the offered message
> * server has auto-create-dead-letter-resources=true for all addresses
> after 10 tries, the server gives up on the message and tries to move it to
> the DLQ address --> OK.
> when the DLQ address does not exist yet, it is created --> OK
> when the queue under DLQ does not exist yet, it is created --> OK
> but moving the message to that queue fails with the above message --> FAIL
> this results in message loss.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-6805) Add defined OSGi services to broker configuration
[ https://issues.apache.org/jira/browse/AMQ-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306091#comment-17306091 ] Jean-Baptiste Onofré commented on AMQ-6805: --- I will change this approach for 5.17, changing activemq-osgi bundle. > Add defined OSGi services to broker configuration > - > > Key: AMQ-6805 > URL: https://issues.apache.org/jira/browse/AMQ-6805 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Affects Versions: 5.15.0, 5.15.1 >Reporter: Benjamin Graf >Assignee: Benjamin Graf >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > ActiveMQ uses Spring for broker configuration. Actually only services defined > via Spring beans are usable. In OSGi it is feasible to register services to > reuse or compose in applications. Therefor the integration from ActiveMQ into > should make it possible to register OSGi services as Spring beans for further > usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned AMQ-6781:
-
Assignee: Jean-Baptiste Onofré
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3196) expose journal pool files in JMX
Andy Taylor created ARTEMIS-3196: Summary: expose journal pool files in JMX Key: ARTEMIS-3196 URL: https://issues.apache.org/jira/browse/ARTEMIS-3196 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Andy Taylor Assignee: Andy Taylor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3196) expose journal pool files in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-3196?focusedWorklogId=569649&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569649 ] ASF GitHub Bot logged work on ARTEMIS-3196: --- Author: ASF GitHub Bot Created on: 22/Mar/21 11:34 Start Date: 22/Mar/21 11:34 Worklog Time Spent: 10m Work Description: andytaylor opened a new pull request #3506: URL: https://github.com/apache/activemq-artemis/pull/3506 https://issues.apache.org/jira/browse/ARTEMIS-3196 -- 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: 569649) Remaining Estimate: 0h Time Spent: 10m > expose journal pool files in JMX > > > Key: ARTEMIS-3196 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3196 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ARTEMIS-2870) CORE connection failure sometimes doesn't cleanup sessions
[
https://issues.apache.org/jira/browse/ARTEMIS-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-2870.
> CORE connection failure sometimes doesn't cleanup sessions
> --
>
> Key: ARTEMIS-2870
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2870
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.10.1, 2.14.0, 2.15.0
>Reporter: Markus Meierhofer
>Priority: Blocker
> Fix For: 2.18.0
>
> Attachments: all_connections_list.png, artemis.log, broker.log,
> broker.xml, connection_nonexistent.png, consumer_list_for_one_queue.png,
> duplicated consumers.png, multiple_consumers_per_queue.png,
> session_with_connection_id.png, three consumers per queue.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Summary
> Since the upgrade of our deployed artemis instances from version 2.6.4 to
> 2.10.1 we have noticed the problem that sometimes, a connection failure
> doesn't include the cleanup of its connected sessions, leading to "zombie"
> consumers and producers on queues.
>
> h3. The issue
> Our Artemis Clients are connected to the broker via the provided JMS
> abstraction, using the default connection TTL of 60 seconds. we are using
> both JMS Topics and JMS Queues.
> As most of our Clients are mobile and in a WiFi, connection losses may occur
> frequently, depending on the quality of the network. When the client is
> disconnected for 60 seconds, the broker usually closes the connection and
> cleans up all the sessions connected to it. The mobile Clients then create
> reconnect when they are online again. What we have noticed is that after many
> connection failures, messages may to be sent twice to the mobile clients.
> When analyzing the problem on the broker console, we found out that there
> were two consumers connected to each of the queues one mobile client usually
> consumes from. One of them belonged to the new connection of the mobile
> Client, which is fine.
> The other consumer belonged to a session whose connection already failed and
> was closed at that time. When analyzing the logs, we saw that for these
> connections, it contained a "Connection failure to ... has been detected"
> line, but no following "clearing up resources for session ..." log lines for
> these connections.
>
> h3. Instance of the issue
>
> The broken Session is the "7a9292cb-xxx" in the picture. In the logs you can
> see that the connection failure was detected, but the session was never
> cleared by the broker (mind the timestamp).
> !duplicated consumers.png!
> {code:java}
> [WARN 2020-07-27 14:33:29,794 Thread-13
> org.apache.activemq.artemis.core.client]: AMQ212037: Connection failure to
> /10.255.0.2:54812 has been detected: syscall:read(..) failed: Connection
> reset by peer [code=GENERIC_EXCEPTION]
> [WARN 2020-07-29 09:31:30,828 Thread-20
> org.apache.activemq.artemis.core.client]: AMQ212037: Connection failure to
> /10.255.0.2:55994 has been detected: AMQ229014: Did not receive data from
> /10.255.0.2:55994 within the 60,000ms connection TTL. The connection will now
> be closed. [code=CONNECTION_TIMEDOUT]
> {code}
>
> Attached you can find the full [^artemis.log] and our [^broker.xml]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3197) Add selectorAware option to the openwire virtualTopicConsumerWildcards feature
Gary Tully created ARTEMIS-3197: --- Summary: Add selectorAware option to the openwire virtualTopicConsumerWildcards feature Key: ARTEMIS-3197 URL: https://issues.apache.org/jira/browse/ARTEMIS-3197 Project: ActiveMQ Artemis Issue Type: Improvement Components: OpenWire Affects Versions: 2.17.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.18.0 [VirtualTopics|https://activemq.apache.org/virtual-destinations.html] support the selector aware option, which filters messages at the point of fanout based on the consumers selector. queues have the option to filter messages, with auto creation, the selector from the openwire consumers info can be used to apply a queue filter. Unmatched messages are not routed in this case. Unlike classic virtual topics, the selector/filter is persisted by default and there is no need for the selector cache plugin. The virtualTopicConsumerWildcards configuration for the openwire acceptor needs an optional selectorAware parameter to support this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3190) AMQ222289: Did not route to any matching bindings on dead-letter-address DLQ and auto-create-dead-letter-resources is true
[
https://issues.apache.org/jira/browse/ARTEMIS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306202#comment-17306202
]
Justin Bertram commented on ARTEMIS-3190:
-
At least one part of the issue is that the selector for the auto-created
dead-letter queue expects the original address (i.e. where the message was sent
originally) to match the address of the queue where the message is being
consumed, but in the wild-card case this expectation is invalid.
I think I've got a fix locally, but it may not cover all edge cases. I'm still
investigating.
> AMQ89: Did not route to any matching bindings on dead-letter-address DLQ
> and auto-create-dead-letter-resources is true
> --
>
> Key: ARTEMIS-3190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3190
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> When a client rollbacks the offered messages, the following error is visible:
> {noformat}
> WARN [org.apache.activemq.artemis.core.server] AMQ89: Did not route to
> any matching bindings on dead-letter-address DLQ and
> auto-create-dead-letter-resources is true; dropping message:
> Reference[375]:RELIABLE:AMQPStandardMessage( [durable=true, messageID=375,
> address=x1, size=189, applicationProperties={},
> properties=Properties{messageId=8bedcf71-a878-469f-9fdf-937c3dc44a02,
> userId=null, to='x1', subject='null', replyTo='null', correlationId=null,
> contentType=null, contentEncoding=null, absoluteExpiryTime=null,
> creationTime=Fri Mar 19 12:07:02 UTC 2021, groupId='null',
> groupSequence=null, replyToGroupId='null'}, extraProperties =
> TypedProperties[_AMQ_AD=x1]]
> {noformat}
> The original source code of Artemis says "this shouldn't happen, but in case
> it does it's better to log a message than just drop the message silently".
> And indeed the message is dropped.
> setup:
> * use a client that uses createSession(true, Session.CLIENT_ACKNOWLEDGE)
> * let the client always rollback the offered message
> * server has auto-create-dead-letter-resources=true for all addresses
> after 10 tries, the server gives up on the message and tries to move it to
> the DLQ address --> OK.
> when the DLQ address does not exist yet, it is created --> OK
> when the queue under DLQ does not exist yet, it is created --> OK
> but moving the message to that queue fails with the above message --> FAIL
> this results in message loss.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3190) AMQ222289: Did not route to any matching bindings on dead-letter-address DLQ and auto-create-dead-letter-resources is true
[
https://issues.apache.org/jira/browse/ARTEMIS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306248#comment-17306248
]
Erwin Dondorp commented on ARTEMIS-3190:
[~gtully] I did not understand your remark. but that is of course ok when it
was not intended for me :-)
[~jbertram] that sounds promising!
> AMQ89: Did not route to any matching bindings on dead-letter-address DLQ
> and auto-create-dead-letter-resources is true
> --
>
> Key: ARTEMIS-3190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3190
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Major
>
> When a client rollbacks the offered messages, the following error is visible:
> {noformat}
> WARN [org.apache.activemq.artemis.core.server] AMQ89: Did not route to
> any matching bindings on dead-letter-address DLQ and
> auto-create-dead-letter-resources is true; dropping message:
> Reference[375]:RELIABLE:AMQPStandardMessage( [durable=true, messageID=375,
> address=x1, size=189, applicationProperties={},
> properties=Properties{messageId=8bedcf71-a878-469f-9fdf-937c3dc44a02,
> userId=null, to='x1', subject='null', replyTo='null', correlationId=null,
> contentType=null, contentEncoding=null, absoluteExpiryTime=null,
> creationTime=Fri Mar 19 12:07:02 UTC 2021, groupId='null',
> groupSequence=null, replyToGroupId='null'}, extraProperties =
> TypedProperties[_AMQ_AD=x1]]
> {noformat}
> The original source code of Artemis says "this shouldn't happen, but in case
> it does it's better to log a message than just drop the message silently".
> And indeed the message is dropped.
> setup:
> * use a client that uses createSession(true, Session.CLIENT_ACKNOWLEDGE)
> * let the client always rollback the offered message
> * server has auto-create-dead-letter-resources=true for all addresses
> after 10 tries, the server gives up on the message and tries to move it to
> the DLQ address --> OK.
> when the DLQ address does not exist yet, it is created --> OK
> when the queue under DLQ does not exist yet, it is created --> OK
> but moving the message to that queue fails with the above message --> FAIL
> this results in message loss.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-355) Duplex bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306252#comment-17306252 ] Justin Bertram commented on ARTEMIS-355: [~clebertsuconic], could the new broker connection feature you implemented recently work for this? > Duplex bridges > -- > > Key: ARTEMIS-355 > URL: https://issues.apache.org/jira/browse/ARTEMIS-355 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.2.0 >Reporter: Mike Hearn >Priority: Major > Fix For: unscheduled > > > I can't find any way to make an embedded artemis A connect to an embedded > artemis B such that B can send messages to A without connectivity at the TCP > level, e.g. due to firewall traversal. It'd be convenient if there was no > need for me to implement firewall punching myself. Apparently ActiveMQ can do > this using some sort of "duplex" attribute, but it's not in Artemis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306276#comment-17306276
]
ASF subversion and git services commented on AMQ-6781:
--
Commit 680b80aa22063e009b14ec59df54c60fdb17d975 in activemq's branch
refs/heads/master from Sami Nurminen
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=680b80a ]
AMQ-6781 - The ActiveMQ Web Console doesn’t support a plus (+) sign in the
ClientID
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?focusedWorklogId=569773&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569773
]
ASF GitHub Bot logged work on AMQ-6781:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 15:12
Start Date: 22/Mar/21 15:12
Worklog Time Spent: 10m
Work Description: jbonofre merged pull request #279:
URL: https://github.com/apache/activemq/pull/279
--
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: 569773)
Time Spent: 0.5h (was: 20m)
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306278#comment-17306278
]
ASF subversion and git services commented on AMQ-6781:
--
Commit 5fcb388741aaa60554828316a4581b824b5693a3 in activemq's branch
refs/heads/master from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=5fcb388 ]
Merge pull request #279 from snurmine/AMQ-6781
AMQ-6781 - The ActiveMQ Web Console doesn’t support a plus (+) sign i…
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306277#comment-17306277
]
ASF subversion and git services commented on AMQ-6781:
--
Commit 5fcb388741aaa60554828316a4581b824b5693a3 in activemq's branch
refs/heads/master from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=5fcb388 ]
Merge pull request #279 from snurmine/AMQ-6781
AMQ-6781 - The ActiveMQ Web Console doesn’t support a plus (+) sign i…
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306281#comment-17306281
]
ASF subversion and git services commented on AMQ-6781:
--
Commit 7e70e4c78c6042d86adb9d8f324c8d0f6092b645 in activemq's branch
refs/heads/activemq-5.15.x from Sami Nurminen
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=7e70e4c ]
AMQ-6781 - The ActiveMQ Web Console doesn’t support a plus (+) sign in the
ClientID
(cherry picked from commit 680b80aa22063e009b14ec59df54c60fdb17d975)
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306280#comment-17306280
]
ASF subversion and git services commented on AMQ-6781:
--
Commit 31628a2a67fd4cd0844d80e75e7a4f1a30176c69 in activemq's branch
refs/heads/activemq-5.16.x from Sami Nurminen
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=31628a2 ]
AMQ-6781 - The ActiveMQ Web Console doesn’t support a plus (+) sign in the
ClientID
(cherry picked from commit 680b80aa22063e009b14ec59df54c60fdb17d975)
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
[
https://issues.apache.org/jira/browse/AMQ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré resolved AMQ-6781.
---
Fix Version/s: 5.16.2
5.15.15
5.17.0
Resolution: Fixed
> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
>
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 5.17.0, 5.15.15, 5.16.2
>
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID.
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00");
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console |
> Connections page :
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL.
> It is : *{color:red}+{color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
Anton Roskvist created ARTEMIS-3198: --- Summary: Add ability to increase concurrency on core bridges Key: ARTEMIS-3198 URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 Project: ActiveMQ Artemis Issue Type: New Feature Components: Broker Reporter: Anton Roskvist Add ability to increase concurrency on core bridges. This is useful for deploying bridges over high latency networks when the message volume is high. More concurrency allows for increased throughput -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Roskvist updated ARTEMIS-3198: Description: Add ability to increase concurrency on core bridges. This is useful for deploying bridges over high latency networks when the message volume is high. More concurrency allows for increased throughput. I have run some tests locally, sending 20k messages across a WAN link. Using the default setting I was able to move all messages from point A to point B in: 2m5s31ms Adding another bridge, with identical parameters besides the name, the same 20k messages where moved in: 1min6s14ms Adding a third means: 33s.19ms So this is pretty much linear increase in throughput based on the number of bridges configured for the same destination. This works, but if multiple queues and destinations are involved the config file gets quite messy. Therefor I propose the addition of a concurrency property for these bridges, which basically spawns N amount of bridges behind the scenes instead, keeping the config file nice and tidy and the messages flying. Test summary: 20k messages (identical across runs), point A to point B over WAN: 1 bridge : 2m 5s 31ms 2 bridges: 1m 6s 14ms 3 bridges: 33s 19ms Br, Anton was:Add ability to increase concurrency on core bridges. This is useful for deploying bridges over high latency networks when the message volume is high. More concurrency allows for increased throughput > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-355) Duplex bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306325#comment-17306325 ] Clebert Suconic commented on ARTEMIS-355: - It sure can... You can create a broker connection to any broker.. and decide on the direction of the bridges.. in or out... you can have many ways to use the feature. I think we should close this one. > Duplex bridges > -- > > Key: ARTEMIS-355 > URL: https://issues.apache.org/jira/browse/ARTEMIS-355 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.2.0 >Reporter: Mike Hearn >Priority: Major > Fix For: unscheduled > > > I can't find any way to make an embedded artemis A connect to an embedded > artemis B such that B can send messages to A without connectivity at the TCP > level, e.g. due to firewall traversal. It'd be convenient if there was no > need for me to implement firewall punching myself. Apparently ActiveMQ can do > this using some sort of "duplex" attribute, but it's not in Artemis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3199) Upgrade postgresql to 42.2.19
Domenico Francesco Bruscino created ARTEMIS-3199: Summary: Upgrade postgresql to 42.2.19 Key: ARTEMIS-3199 URL: https://issues.apache.org/jira/browse/ARTEMIS-3199 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Domenico Francesco Bruscino Assignee: Domenico Francesco Bruscino According to the [postgresql documentation|https://jdbc.postgresql.org/documentation/faq.html#42-is-not] The 42.x.x releases are not a rewrite of the driver, are not using a new architecture, nor are using something special, they are the continuation of the same driver following a better versioning policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306335#comment-17306335 ] Clebert Suconic commented on ARTEMIS-3198: -- Can't you do that through Broker connection? on that case you could then have two or more broker connections with a sender between one broker towards the other. > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3199) Upgrade postgresql to 42.2.19
[ https://issues.apache.org/jira/browse/ARTEMIS-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino updated ARTEMIS-3199: - Description: According to the [postgresql documentation|https://jdbc.postgresql.org/documentation/faq.html#42-is-not], the 42.x.x releases are not a rewrite of the driver, are not using a new architecture, nor are using something special, they are the continuation of the same driver following a better versioning policy. (was: According to the [postgresql documentation|https://jdbc.postgresql.org/documentation/faq.html#42-is-not] The 42.x.x releases are not a rewrite of the driver, are not using a new architecture, nor are using something special, they are the continuation of the same driver following a better versioning policy.) > Upgrade postgresql to 42.2.19 > -- > > Key: ARTEMIS-3199 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3199 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > According to the [postgresql > documentation|https://jdbc.postgresql.org/documentation/faq.html#42-is-not], > the 42.x.x releases are not a rewrite of the driver, are not using a new > architecture, nor are using something special, they are the continuation of > the same driver following a better versioning policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3199) Upgrade postgresql to 42.2.19
[ https://issues.apache.org/jira/browse/ARTEMIS-3199?focusedWorklogId=569833&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569833 ] ASF GitHub Bot logged work on ARTEMIS-3199: --- Author: ASF GitHub Bot Created on: 22/Mar/21 16:20 Start Date: 22/Mar/21 16:20 Worklog Time Spent: 10m Work Description: brusdev opened a new pull request #3507: URL: https://github.com/apache/activemq-artemis/pull/3507 According to the [postgresql documentation](https://jdbc.postgresql.org/documentation/faq.html#42-is-not), the 42.x.x releases are not a rewrite of the driver, are not using a new architecture, nor are using something special, they are the continuation of the same driver following a better versioning policy. -- 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: 569833) Remaining Estimate: 0h Time Spent: 10m > Upgrade postgresql to 42.2.19 > -- > > Key: ARTEMIS-3199 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3199 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > According to the [postgresql > documentation|https://jdbc.postgresql.org/documentation/faq.html#42-is-not] > The 42.x.x releases are not a rewrite of the driver, are not using a new > architecture, nor are using something special, they are the continuation of > the same driver following a better versioning policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3150) wrong username in error message for AMQP connections
[
https://issues.apache.org/jira/browse/ARTEMIS-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306337#comment-17306337
]
Clebert Suconic commented on ARTEMIS-3150:
--
just to update progress... I wrote tests locally that are using the
smoke-tests.. and sending and receiving messages through broker connections..
exercising the issue and replicating the problems.
I should be able to commit a solution this week, perhaps we can release it next
week with the fix in place. (not promising yet but trying)
> wrong username in error message for AMQP connections
>
>
> Key: ARTEMIS-3150
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3150
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Attachments: A.log, B.log, brokerA.xml, brokerB.xml, login.config
>
>
> I'm connecting independent brokers A and B using the {{broker-connections}}
> mechanism. A connects to B.
> Using URI, NAME, USER and PASSWORD attributes. The password is wrong on
> purpose.
> On the A side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from B/192.168.208.3:5672. Username: null; SSL certificate
> subject DN: unavailable
> {noformat}
> which btw is immediately shown also as an exception:
> {noformat}
> AMQ229031: Unable to validate user from shore01/192.168.208.3:5672. Username:
> null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from B/192.168.208.3:5672. Username: null; SSL
> certificate subject DN: unavailable]
> {noformat}
> both the message and the exception show {{Username: null}}, which is not the
> given username.
> On the B side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from /192.168.208.2:38180. Username: ; SSL certificate
> subject DN: unavailable
> {noformat}
> this message shows the correct username.
> So the error message that gets returned from B to A is not the same and has
> less useful information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306350#comment-17306350 ] Anton Roskvist commented on ARTEMIS-3198: - Not from what I could work out anyway, or how would you set that up? Setting multiple "connector-ref" towards the same broker? > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQ-7050) Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
[
https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=569854&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569854
]
ASF GitHub Bot logged work on AMQ-7050:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 16:54
Start Date: 22/Mar/21 16:54
Worklog Time Spent: 10m
Work Description: jbonofre commented on a change in pull request #297:
URL: https://github.com/apache/activemq/pull/297#discussion_r598902108
##
File path:
activemq-broker/src/main/java/org/apache/activemq/plugin/SubQueueSelectorCacheBroker.java
##
@@ -58,39 +49,27 @@
* https://issues.apache.org/activemq/browse/AMQ-3004
*
http://mail-archives.apache.org/mod_mbox/activemq-users/201011.mbox/%3c8a013711-2613-450a-a487-379e784af...@homeaway.co.uk%3E
*/
-public class SubQueueSelectorCacheBroker extends BrokerFilter implements
Runnable {
+public class SubQueueSelectorCacheBroker extends BrokerFilter {
private static final Logger LOG =
LoggerFactory.getLogger(SubQueueSelectorCacheBroker.class);
public static final String MATCH_EVERYTHING = "TRUE";
/**
* The subscription's selector cache. We cache compiled expressions keyed
* by the target destination.
*/
-private ConcurrentMap> subSelectorCache = new
ConcurrentHashMap>();
+private final SubSelectorCache subSelectorCache;
-private final File persistFile;
private boolean singleSelectorPerDestination = false;
private boolean ignoreWildcardSelectors = false;
private ObjectName objectName;
-private boolean running = true;
-private final Thread persistThread;
-private long persistInterval = MAX_PERSIST_INTERVAL;
-public static final long MAX_PERSIST_INTERVAL = 60;
-private static final String SELECTOR_CACHE_PERSIST_THREAD_NAME =
"SelectorCachePersistThread";
-
/**
* Constructor
*/
-public SubQueueSelectorCacheBroker(Broker next, final File persistFile) {
+public SubQueueSelectorCacheBroker(Broker next, final SubSelectorCache
subSelectorCache) {
Review comment:
Instead of changing the default behavior, I would rather create a
totally new plugin, extending `SubQueueSelectorCacheBroker`. I think the
configuration would be easier and less confusing for the users.
--
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: 569854)
Time Spent: 0.5h (was: 20m)
> Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
>
>
> Key: AMQ-7050
> URL: https://issues.apache.org/jira/browse/AMQ-7050
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: Alec Henninger
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> (Largely copied from my email to dev list)
> Background: We're running a multitenant activemq pair using selector aware
> virtual topics extensively but also need truly durable subscriptions. The
> SubQueueSelectorCacheBroker plugin was developed for this purpose as we
> understand, however it persists the selector cache in a File, and we'd like
> to instead use a shared/replicated cache that doesn't depend on a node first
> storing the cached consumer selector locally first. The reason for this is,
> with the current implementation, there is an edge case where if both:
> 1. A active broker has not yet cached a consumer's selector (e.g. secondary
> broker becomes primary that hasn't yet received connection from said consumer
> and brokers are not sharing networked file system)
> 2. Producer connects and starts publishing messages before consumer
> ...then those messages will be lost. In some domains, any message loss is
> really undesirable so we want to do everything we can to prevent that while
> still using selector aware virtual topics. We'd just turn off selectorAware,
> but then we have to deal with message build up for consumers using selectors,
> and we have little control over how/when consumers use selectors.
> Hence, refactoring SubQueueSelectorCacheBroker to allow an alternate source
> of persistence enables us to experiment with a fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-7050) Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
[ https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=569857&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569857 ] ASF GitHub Bot logged work on AMQ-7050: --- Author: ASF GitHub Bot Created on: 22/Mar/21 16:55 Start Date: 22/Mar/21 16:55 Worklog Time Spent: 10m Work Description: jbonofre commented on pull request #297: URL: https://github.com/apache/activemq/pull/297#issuecomment-804226802 @alechenninger do you have time to refactore this PR as a complete new plugin or do you want me to do it ? Thanks ! -- 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: 569857) Time Spent: 40m (was: 0.5h) > Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin > > > Key: AMQ-7050 > URL: https://issues.apache.org/jira/browse/AMQ-7050 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.15.6 >Reporter: Alec Henninger >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > (Largely copied from my email to dev list) > Background: We're running a multitenant activemq pair using selector aware > virtual topics extensively but also need truly durable subscriptions. The > SubQueueSelectorCacheBroker plugin was developed for this purpose as we > understand, however it persists the selector cache in a File, and we'd like > to instead use a shared/replicated cache that doesn't depend on a node first > storing the cached consumer selector locally first. The reason for this is, > with the current implementation, there is an edge case where if both: > 1. A active broker has not yet cached a consumer's selector (e.g. secondary > broker becomes primary that hasn't yet received connection from said consumer > and brokers are not sharing networked file system) > 2. Producer connects and starts publishing messages before consumer > ...then those messages will be lost. In some domains, any message loss is > really undesirable so we want to do everything we can to prevent that while > still using selector aware virtual topics. We'd just turn off selectorAware, > but then we have to deal with message build up for consumers using selectors, > and we have little control over how/when consumers use selectors. > Hence, refactoring SubQueueSelectorCacheBroker to allow an alternate source > of persistence enables us to experiment with a fix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQ-7050) Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
[
https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=569861&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569861
]
ASF GitHub Bot logged work on AMQ-7050:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 17:03
Start Date: 22/Mar/21 17:03
Worklog Time Spent: 10m
Work Description: mattrpav commented on a change in pull request #297:
URL: https://github.com/apache/activemq/pull/297#discussion_r598909652
##
File path:
activemq-broker/src/main/java/org/apache/activemq/plugin/SubQueueSelectorCacheBroker.java
##
@@ -58,39 +49,27 @@
* https://issues.apache.org/activemq/browse/AMQ-3004
*
http://mail-archives.apache.org/mod_mbox/activemq-users/201011.mbox/%3c8a013711-2613-450a-a487-379e784af...@homeaway.co.uk%3E
*/
-public class SubQueueSelectorCacheBroker extends BrokerFilter implements
Runnable {
+public class SubQueueSelectorCacheBroker extends BrokerFilter {
private static final Logger LOG =
LoggerFactory.getLogger(SubQueueSelectorCacheBroker.class);
public static final String MATCH_EVERYTHING = "TRUE";
/**
* The subscription's selector cache. We cache compiled expressions keyed
* by the target destination.
*/
-private ConcurrentMap> subSelectorCache = new
ConcurrentHashMap>();
+private final SubSelectorCache subSelectorCache;
-private final File persistFile;
private boolean singleSelectorPerDestination = false;
private boolean ignoreWildcardSelectors = false;
private ObjectName objectName;
-private boolean running = true;
-private final Thread persistThread;
-private long persistInterval = MAX_PERSIST_INTERVAL;
-public static final long MAX_PERSIST_INTERVAL = 60;
-private static final String SELECTOR_CACHE_PERSIST_THREAD_NAME =
"SelectorCachePersistThread";
-
/**
* Constructor
*/
-public SubQueueSelectorCacheBroker(Broker next, final File persistFile) {
+public SubQueueSelectorCacheBroker(Broker next, final SubSelectorCache
subSelectorCache) {
Review comment:
+1 JB
--
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: 569861)
Time Spent: 50m (was: 40m)
> Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
>
>
> Key: AMQ-7050
> URL: https://issues.apache.org/jira/browse/AMQ-7050
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: Alec Henninger
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> (Largely copied from my email to dev list)
> Background: We're running a multitenant activemq pair using selector aware
> virtual topics extensively but also need truly durable subscriptions. The
> SubQueueSelectorCacheBroker plugin was developed for this purpose as we
> understand, however it persists the selector cache in a File, and we'd like
> to instead use a shared/replicated cache that doesn't depend on a node first
> storing the cached consumer selector locally first. The reason for this is,
> with the current implementation, there is an edge case where if both:
> 1. A active broker has not yet cached a consumer's selector (e.g. secondary
> broker becomes primary that hasn't yet received connection from said consumer
> and brokers are not sharing networked file system)
> 2. Producer connects and starts publishing messages before consumer
> ...then those messages will be lost. In some domains, any message loss is
> really undesirable so we want to do everything we can to prevent that while
> still using selector aware virtual topics. We'd just turn off selectorAware,
> but then we have to deal with message build up for consumers using selectors,
> and we have little control over how/when consumers use selectors.
> Hence, refactoring SubQueueSelectorCacheBroker to allow an alternate source
> of persistence enables us to experiment with a fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3197) Add selectorAware option to the openwire virtualTopicConsumerWildcards feature
[ https://issues.apache.org/jira/browse/ARTEMIS-3197?focusedWorklogId=569889&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569889 ] ASF GitHub Bot logged work on ARTEMIS-3197: --- Author: ASF GitHub Bot Created on: 22/Mar/21 17:33 Start Date: 22/Mar/21 17:33 Worklog Time Spent: 10m Work Description: gtully opened a new pull request #3508: URL: https://github.com/apache/activemq-artemis/pull/3508 …rds for openwire acceptor -- 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: 569889) Remaining Estimate: 0h Time Spent: 10m > Add selectorAware option to the openwire virtualTopicConsumerWildcards feature > -- > > Key: ARTEMIS-3197 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3197 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 10m > Remaining Estimate: 0h > > [VirtualTopics|https://activemq.apache.org/virtual-destinations.html] support > the selector aware option, which filters messages at the point of fanout > based on the consumers selector. > queues have the option to filter messages, with auto creation, the selector > from the openwire consumers info can be used to apply a queue filter. > Unmatched messages are not routed in this case. > Unlike classic virtual topics, the selector/filter is persisted by default > and there is no need for the selector cache plugin. > The virtualTopicConsumerWildcards configuration for the openwire acceptor > needs an optional selectorAware parameter to support this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=569892&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569892 ] ASF GitHub Bot logged work on ARTEMIS-3198: --- Author: ASF GitHub Bot Created on: 22/Mar/21 17:37 Start Date: 22/Mar/21 17:37 Worklog Time Spent: 10m Work Description: AntonRoskvist opened a new pull request #3509: URL: https://github.com/apache/activemq-artemis/pull/3509 This commit adds a concurrency-option for the core bridges to handle high latency networks better -- 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: 569892) Remaining Estimate: 0h Time Spent: 10m > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=569900&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569900 ] ASF GitHub Bot logged work on ARTEMIS-3198: --- Author: ASF GitHub Bot Created on: 22/Mar/21 17:43 Start Date: 22/Mar/21 17:43 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3509: URL: https://github.com/apache/activemq-artemis/pull/3509#issuecomment-804263399 Nice contribution!! Just curious, as we have made with ReplicationManager on https://github.com/apache/activemq-artemis/pull/3392 probably we are not correctly filling enough packets to maximize the TCP packet size and amortize network latencies: have you tried by disabling TCP no delay 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: 569900) Time Spent: 20m (was: 10m) > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[
https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=569904&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569904
]
ASF GitHub Bot logged work on ARTEMIS-3198:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 17:51
Start Date: 22/Mar/21 17:51
Worklog Time Spent: 10m
Work Description: jbertram commented on a change in pull request #3509:
URL: https://github.com/apache/activemq-artemis/pull/3509#discussion_r598947715
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/ClusterManager.java
##
@@ -475,16 +475,21 @@ public synchronized void deployBridge(final
BridgeConfiguration config) throws E
clusterLocators.add(serverLocator);
- Bridge bridge = new BridgeImpl(serverLocator,
config.getInitialConnectAttempts(), config.getReconnectAttempts(),
config.getReconnectAttemptsOnSameNode(), config.getRetryInterval(),
config.getRetryIntervalMultiplier(), config.getMaxRetryInterval(),
nodeManager.getUUID(), new SimpleString(config.getName()), queue,
executorFactory.getExecutor(),
FilterImpl.createFilter(config.getFilterString()),
SimpleString.toSimpleString(config.getForwardingAddress()), scheduledExecutor,
transformer, config.isUseDuplicateDetection(), config.getUser(),
config.getPassword(), server, config.getRoutingType());
-
- bridges.put(config.getName(), bridge);
-
- managementService.registerBridge(bridge, config);
-
- bridge.start();
-
- if (server.hasBrokerBridgePlugins()) {
- server.callBrokerBridgePlugins(plugin ->
plugin.afterDeployBridge(bridge));
+ for (int i = 0; i < config.getConcurrency(); i++) {
+ Bridge bridge = new BridgeImpl(serverLocator,
config.getInitialConnectAttempts(), config.getReconnectAttempts(),
+ config.getReconnectAttemptsOnSameNode(),
config.getRetryInterval(), config.getRetryIntervalMultiplier(),
+ config.getMaxRetryInterval(), nodeManager.getUUID(), new
SimpleString(config.getName()), queue,
Review comment:
You need to change the name of each bridge (e.g. `config.getName() + "-"
+ i`) so that it's unique otherwise you won't be able to manage them (if
necessary).
--
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: 569904)
Time Spent: 0.5h (was: 20m)
> Add ability to increase concurrency on core bridges
> ---
>
> Key: ARTEMIS-3198
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3198
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Anton Roskvist
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add ability to increase concurrency on core bridges. This is useful for
> deploying bridges over high latency networks when the message volume is high.
> More concurrency allows for increased throughput.
>
> I have run some tests locally, sending 20k messages across a WAN link. Using
> the default setting I was able to move all messages from point A to point B
> in: 2m5s31ms
> Adding another bridge, with identical parameters besides the name, the same
> 20k messages where moved in: 1min6s14ms
> Adding a third means: 33s.19ms
> So this is pretty much linear increase in throughput based on the number of
> bridges configured for the same destination. This works, but if multiple
> queues and destinations are involved the config file gets quite messy.
> Therefor I propose the addition of a concurrency property for these bridges,
> which basically spawns N amount of bridges behind the scenes instead, keeping
> the config file nice and tidy and the messages flying.
> Test summary:
> 20k messages (identical across runs), point A to point B over WAN:
> 1 bridge : 2m 5s 31ms
> 2 bridges: 1m 6s 14ms
> 3 bridges: 33s 19ms
> Br,
> Anton
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-6892) Test failing unexpectedly: CamelVMTransportRoutingTest.testSendReceiveWithCamelRouteIntercepting
[ https://issues.apache.org/jira/browse/AMQ-6892?focusedWorklogId=569916&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569916 ] ASF GitHub Bot logged work on AMQ-6892: --- Author: ASF GitHub Bot Created on: 22/Mar/21 18:15 Start Date: 22/Mar/21 18:15 Worklog Time Spent: 10m Work Description: jbonofre commented on pull request #273: URL: https://github.com/apache/activemq/pull/273#issuecomment-804285426 I tried several times but it works fine in maven. Maybe only IntelliJ is impacted. -- 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: 569916) Time Spent: 40m (was: 0.5h) > Test failing unexpectedly: > CamelVMTransportRoutingTest.testSendReceiveWithCamelRouteIntercepting > > > Key: AMQ-6892 > URL: https://issues.apache.org/jira/browse/AMQ-6892 > Project: ActiveMQ > Issue Type: Bug > Components: Camel >Affects Versions: 5.16.0 > Environment: Ubuntu, 16.04 LTS >Reporter: Wing Lam >Assignee: Jean-Baptiste Onofré >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > When I run the test > CamelVMTransportRoutingTest.testSendReceiveWithCamelRouteIntercepting, it > passes, but when I run all of the tests in activemq-camel, it fails. I am > running this in Intellij. > It appears the problem is unclosed connections in some of the other tests. > Changes that fix this can be seen in the pull request linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQ-6892) Test failing unexpectedly: CamelVMTransportRoutingTest.testSendReceiveWithCamelRouteIntercepting
[ https://issues.apache.org/jira/browse/AMQ-6892?focusedWorklogId=569915&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569915 ] ASF GitHub Bot logged work on AMQ-6892: --- Author: ASF GitHub Bot Created on: 22/Mar/21 18:15 Start Date: 22/Mar/21 18:15 Worklog Time Spent: 10m Work Description: jbonofre closed pull request #273: URL: https://github.com/apache/activemq/pull/273 -- 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: 569915) Time Spent: 0.5h (was: 20m) > Test failing unexpectedly: > CamelVMTransportRoutingTest.testSendReceiveWithCamelRouteIntercepting > > > Key: AMQ-6892 > URL: https://issues.apache.org/jira/browse/AMQ-6892 > Project: ActiveMQ > Issue Type: Bug > Components: Camel >Affects Versions: 5.16.0 > Environment: Ubuntu, 16.04 LTS >Reporter: Wing Lam >Assignee: Jean-Baptiste Onofré >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > When I run the test > CamelVMTransportRoutingTest.testSendReceiveWithCamelRouteIntercepting, it > passes, but when I run all of the tests in activemq-camel, it fails. I am > running this in Intellij. > It appears the problem is unclosed connections in some of the other tests. > Changes that fix this can be seen in the pull request linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQ-7050) Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
[
https://issues.apache.org/jira/browse/AMQ-7050?focusedWorklogId=569941&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569941
]
ASF GitHub Bot logged work on AMQ-7050:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 19:05
Start Date: 22/Mar/21 19:05
Worklog Time Spent: 10m
Work Description: mattrpav commented on a change in pull request #297:
URL: https://github.com/apache/activemq/pull/297#discussion_r598909652
##
File path:
activemq-broker/src/main/java/org/apache/activemq/plugin/SubQueueSelectorCacheBroker.java
##
@@ -58,39 +49,27 @@
* https://issues.apache.org/activemq/browse/AMQ-3004
*
http://mail-archives.apache.org/mod_mbox/activemq-users/201011.mbox/%3c8a013711-2613-450a-a487-379e784af...@homeaway.co.uk%3E
*/
-public class SubQueueSelectorCacheBroker extends BrokerFilter implements
Runnable {
+public class SubQueueSelectorCacheBroker extends BrokerFilter {
private static final Logger LOG =
LoggerFactory.getLogger(SubQueueSelectorCacheBroker.class);
public static final String MATCH_EVERYTHING = "TRUE";
/**
* The subscription's selector cache. We cache compiled expressions keyed
* by the target destination.
*/
-private ConcurrentMap> subSelectorCache = new
ConcurrentHashMap>();
+private final SubSelectorCache subSelectorCache;
-private final File persistFile;
private boolean singleSelectorPerDestination = false;
private boolean ignoreWildcardSelectors = false;
private ObjectName objectName;
-private boolean running = true;
-private final Thread persistThread;
-private long persistInterval = MAX_PERSIST_INTERVAL;
-public static final long MAX_PERSIST_INTERVAL = 60;
-private static final String SELECTOR_CACHE_PERSIST_THREAD_NAME =
"SelectorCachePersistThread";
-
/**
* Constructor
*/
-public SubQueueSelectorCacheBroker(Broker next, final File persistFile) {
+public SubQueueSelectorCacheBroker(Broker next, final SubSelectorCache
subSelectorCache) {
Review comment:
+1 on JB suggestion. Improvement is a good idea, but let's not break
previous users.
Perhaps even make the improvement the default (or recommended) in 5.17.0
--
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: 569941)
Time Spent: 1h (was: 50m)
> Allow alternate persistence mechanism with SubQueueSelectorCacheBrokerPlugin
>
>
> Key: AMQ-7050
> URL: https://issues.apache.org/jira/browse/AMQ-7050
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: Alec Henninger
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> (Largely copied from my email to dev list)
> Background: We're running a multitenant activemq pair using selector aware
> virtual topics extensively but also need truly durable subscriptions. The
> SubQueueSelectorCacheBroker plugin was developed for this purpose as we
> understand, however it persists the selector cache in a File, and we'd like
> to instead use a shared/replicated cache that doesn't depend on a node first
> storing the cached consumer selector locally first. The reason for this is,
> with the current implementation, there is an edge case where if both:
> 1. A active broker has not yet cached a consumer's selector (e.g. secondary
> broker becomes primary that hasn't yet received connection from said consumer
> and brokers are not sharing networked file system)
> 2. Producer connects and starts publishing messages before consumer
> ...then those messages will be lost. In some domains, any message loss is
> really undesirable so we want to do everything we can to prevent that while
> still using selector aware virtual topics. We'd just turn off selectorAware,
> but then we have to deal with message build up for consumers using selectors,
> and we have little control over how/when consumers use selectors.
> Hence, refactoring SubQueueSelectorCacheBroker to allow an alternate source
> of persistence enables us to experiment with a fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch
[
https://issues.apache.org/jira/browse/AMQ-7072?focusedWorklogId=569973&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569973
]
ASF GitHub Bot logged work on AMQ-7072:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 19:32
Start Date: 22/Mar/21 19:32
Worklog Time Spent: 10m
Work Description: mattrpav commented on pull request #308:
URL: https://github.com/apache/activemq/pull/308#issuecomment-804337509
Thoughts on moving the requirement to json-b spec api, but staying with
Jackson as impl?
--
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: 569973)
Time Spent: 0.5h (was: 20m)
> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.16.0
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The regression we hit at the moment is that activemq enforces TomEE to import
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B
> spec is out and implemented by both I guess it can be the way to solve that
> issue.
> The most blocking thing is
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
> - which can already not create a mapper if json is empty ;) - but here is
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch
[
https://issues.apache.org/jira/browse/AMQ-7072?focusedWorklogId=569977&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569977
]
ASF GitHub Bot logged work on AMQ-7072:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 19:35
Start Date: 22/Mar/21 19:35
Worklog Time Spent: 10m
Work Description: mattrpav removed a comment on pull request #308:
URL: https://github.com/apache/activemq/pull/308#issuecomment-804337509
Thoughts on moving the requirement to json-b spec api, but staying with
Jackson as impl?
--
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: 569977)
Time Spent: 40m (was: 0.5h)
> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.16.0
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The regression we hit at the moment is that activemq enforces TomEE to import
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B
> spec is out and implemented by both I guess it can be the way to solve that
> issue.
> The most blocking thing is
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
> - which can already not create a mapper if json is empty ;) - but here is
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch
[
https://issues.apache.org/jira/browse/AMQ-7072?focusedWorklogId=569990&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569990
]
ASF GitHub Bot logged work on AMQ-7072:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 19:46
Start Date: 22/Mar/21 19:46
Worklog Time Spent: 10m
Work Description: jbonofre commented on pull request #308:
URL: https://github.com/apache/activemq/pull/308#issuecomment-804346225
Johnzon is fine using jsonb. I've started the review and rebase anyway.
--
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: 569990)
Time Spent: 50m (was: 40m)
> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.16.0
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The regression we hit at the moment is that activemq enforces TomEE to import
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B
> spec is out and implemented by both I guess it can be the way to solve that
> issue.
> The most blocking thing is
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
> - which can already not create a mapper if json is empty ;) - but here is
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[
https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=569994&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569994
]
ASF GitHub Bot logged work on ARTEMIS-3198:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 19:54
Start Date: 22/Mar/21 19:54
Worklog Time Spent: 10m
Work Description: AntonRoskvist commented on a change in pull request
#3509:
URL: https://github.com/apache/activemq-artemis/pull/3509#discussion_r599030504
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/ClusterManager.java
##
@@ -475,16 +475,21 @@ public synchronized void deployBridge(final
BridgeConfiguration config) throws E
clusterLocators.add(serverLocator);
- Bridge bridge = new BridgeImpl(serverLocator,
config.getInitialConnectAttempts(), config.getReconnectAttempts(),
config.getReconnectAttemptsOnSameNode(), config.getRetryInterval(),
config.getRetryIntervalMultiplier(), config.getMaxRetryInterval(),
nodeManager.getUUID(), new SimpleString(config.getName()), queue,
executorFactory.getExecutor(),
FilterImpl.createFilter(config.getFilterString()),
SimpleString.toSimpleString(config.getForwardingAddress()), scheduledExecutor,
transformer, config.isUseDuplicateDetection(), config.getUser(),
config.getPassword(), server, config.getRoutingType());
-
- bridges.put(config.getName(), bridge);
-
- managementService.registerBridge(bridge, config);
-
- bridge.start();
-
- if (server.hasBrokerBridgePlugins()) {
- server.callBrokerBridgePlugins(plugin ->
plugin.afterDeployBridge(bridge));
+ for (int i = 0; i < config.getConcurrency(); i++) {
+ Bridge bridge = new BridgeImpl(serverLocator,
config.getInitialConnectAttempts(), config.getReconnectAttempts(),
+ config.getReconnectAttemptsOnSameNode(),
config.getRetryInterval(), config.getRetryIntervalMultiplier(),
+ config.getMaxRetryInterval(), nodeManager.getUUID(), new
SimpleString(config.getName()), queue,
Review comment:
Added unique naming for all bridges as you recommended, hope it looks
good
--
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: 569994)
Time Spent: 40m (was: 0.5h)
> Add ability to increase concurrency on core bridges
> ---
>
> Key: ARTEMIS-3198
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3198
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Anton Roskvist
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add ability to increase concurrency on core bridges. This is useful for
> deploying bridges over high latency networks when the message volume is high.
> More concurrency allows for increased throughput.
>
> I have run some tests locally, sending 20k messages across a WAN link. Using
> the default setting I was able to move all messages from point A to point B
> in: 2m5s31ms
> Adding another bridge, with identical parameters besides the name, the same
> 20k messages where moved in: 1min6s14ms
> Adding a third means: 33s.19ms
> So this is pretty much linear increase in throughput based on the number of
> bridges configured for the same destination. This works, but if multiple
> queues and destinations are involved the config file gets quite messy.
> Therefor I propose the addition of a concurrency property for these bridges,
> which basically spawns N amount of bridges behind the scenes instead, keeping
> the config file nice and tidy and the messages flying.
> Test summary:
> 20k messages (identical across runs), point A to point B over WAN:
> 1 bridge : 2m 5s 31ms
> 2 bridges: 1m 6s 14ms
> 3 bridges: 33s 19ms
> Br,
> Anton
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=569997&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569997 ] ASF GitHub Bot logged work on ARTEMIS-3198: --- Author: ASF GitHub Bot Created on: 22/Mar/21 20:00 Start Date: 22/Mar/21 20:00 Worklog Time Spent: 10m Work Description: AntonRoskvist commented on pull request #3509: URL: https://github.com/apache/activemq-artemis/pull/3509#issuecomment-804354885 > Nice contribution!! > Just curious, as we have made with ReplicationManager on #3392 probably we are not correctly filling enough packets to maximize the TCP packet size and amortize network latencies: have you tried by disabling TCP no delay too? Thanks, No I haven't tried that and it looks like a real nice optimization, but for my use case I am looking to increase the throughput I am currently seeing by some 10-15 times at least. I will definitely try that out as well though! -- 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: 569997) Time Spent: 50m (was: 40m) > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3150) wrong username in error message for AMQP connections
[
https://issues.apache.org/jira/browse/ARTEMIS-3150?focusedWorklogId=570001&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570001
]
ASF GitHub Bot logged work on ARTEMIS-3150:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 20:02
Start Date: 22/Mar/21 20:02
Worklog Time Spent: 10m
Work Description: clebertsuconic opened a new pull request #3510:
URL: https://github.com/apache/activemq-artemis/pull/3510
The local connections and sessions created internally were supposed to
bypass security
just like bridges and other internal components
--
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: 570001)
Remaining Estimate: 0h
Time Spent: 10m
> wrong username in error message for AMQP connections
>
>
> Key: ARTEMIS-3150
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3150
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Attachments: A.log, B.log, brokerA.xml, brokerB.xml, login.config
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm connecting independent brokers A and B using the {{broker-connections}}
> mechanism. A connects to B.
> Using URI, NAME, USER and PASSWORD attributes. The password is wrong on
> purpose.
> On the A side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from B/192.168.208.3:5672. Username: null; SSL certificate
> subject DN: unavailable
> {noformat}
> which btw is immediately shown also as an exception:
> {noformat}
> AMQ229031: Unable to validate user from shore01/192.168.208.3:5672. Username:
> null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from B/192.168.208.3:5672. Username: null; SSL
> certificate subject DN: unavailable]
> {noformat}
> both the message and the exception show {{Username: null}}, which is not the
> given username.
> On the B side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from /192.168.208.2:38180. Username: ; SSL certificate
> subject DN: unavailable
> {noformat}
> this message shows the correct username.
> So the error message that gets returned from B to A is not the same and has
> less useful information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-7072) ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to support impl switch
[
https://issues.apache.org/jira/browse/AMQ-7072?focusedWorklogId=570005&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570005
]
ASF GitHub Bot logged work on AMQ-7072:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 20:04
Start Date: 22/Mar/21 20:04
Worklog Time Spent: 10m
Work Description: rmannibucau commented on pull request #308:
URL: https://github.com/apache/activemq/pull/308#issuecomment-804356942
Overall the goal is to enable to use json-b and use the json-b contract (ie
neither johnzon nor jackson must appear in compile scope in theory - until it
is to be transitive but I'm speaking on a pure build perspective). I assume it
should be tested with both impl - and maybe yasson - to ensure some portability
- at least manually for the first round.
After the question of the default in the distro can be discussed. The least
changing is jackson but the most apache is johnzon and for AMQ it should be
very close once fully migrated to json-b api so at the end I'd say 50-50 ;).
--
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: 570005)
Time Spent: 1h (was: 50m)
> ActiveMQ shouldn't import jackson but use JSON-B instead of jackson to
> support impl switch
> --
>
> Key: AMQ-7072
> URL: https://issues.apache.org/jira/browse/AMQ-7072
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.16.0
>Reporter: Romain Manni-Bucau
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The regression we hit at the moment is that activemq enforces TomEE to import
> jackson whereas it wants to keep johnzon as JSON mapper impl. Since JSON-B
> spec is out and implemented by both I guess it can be the way to solve that
> issue.
> The most blocking thing is
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java
> - which can already not create a mapper if json is empty ;) - but here is
> the list of code location which would be neat to fix:
> {code}
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonInclude;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.DeserializationConfig;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.SerializationFeature;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java:import
> com.fasterxml.jackson.annotation.JsonProperty;
> ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java:import
> com.fasterxml.jackson.databind.ObjectMapper;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogWrite.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/WalAck.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/LogDelete.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Transfer.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> ./activemq-leveldb-store/src/main/java/org/apache/activemq/leveldb/replicated/dto/Login.java:import
> com.fasterxml.jackson.annotation.JsonIgnoreProperties;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3150) wrong username in error message for AMQP connections
[
https://issues.apache.org/jira/browse/ARTEMIS-3150?focusedWorklogId=570064&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570064
]
ASF GitHub Bot logged work on ARTEMIS-3150:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 21:37
Start Date: 22/Mar/21 21:37
Worklog Time Spent: 10m
Work Description: asfgit merged pull request #3510:
URL: https://github.com/apache/activemq-artemis/pull/3510
--
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: 570064)
Time Spent: 20m (was: 10m)
> wrong username in error message for AMQP connections
>
>
> Key: ARTEMIS-3150
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3150
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Attachments: A.log, B.log, brokerA.xml, brokerB.xml, login.config
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm connecting independent brokers A and B using the {{broker-connections}}
> mechanism. A connects to B.
> Using URI, NAME, USER and PASSWORD attributes. The password is wrong on
> purpose.
> On the A side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from B/192.168.208.3:5672. Username: null; SSL certificate
> subject DN: unavailable
> {noformat}
> which btw is immediately shown also as an exception:
> {noformat}
> AMQ229031: Unable to validate user from shore01/192.168.208.3:5672. Username:
> null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from B/192.168.208.3:5672. Username: null; SSL
> certificate subject DN: unavailable]
> {noformat}
> both the message and the exception show {{Username: null}}, which is not the
> given username.
> On the B side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from /192.168.208.2:38180. Username: ; SSL certificate
> subject DN: unavailable
> {noformat}
> this message shows the correct username.
> So the error message that gets returned from B to A is not the same and has
> less useful information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3150) wrong username in error message for AMQP connections
[
https://issues.apache.org/jira/browse/ARTEMIS-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306596#comment-17306596
]
ASF subversion and git services commented on ARTEMIS-3150:
--
Commit b4beea1f2c2c2cd3292f19a5ec00e2a27d03e671 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b4beea1 ]
ARTEMIS-3150 Broker Connections with restricted security
The local connections and sessions created internally were supposed to bypass
security
just like bridges and other internal components
> wrong username in error message for AMQP connections
>
>
> Key: ARTEMIS-3150
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3150
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Attachments: A.log, B.log, brokerA.xml, brokerB.xml, login.config
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm connecting independent brokers A and B using the {{broker-connections}}
> mechanism. A connects to B.
> Using URI, NAME, USER and PASSWORD attributes. The password is wrong on
> purpose.
> On the A side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from B/192.168.208.3:5672. Username: null; SSL certificate
> subject DN: unavailable
> {noformat}
> which btw is immediately shown also as an exception:
> {noformat}
> AMQ229031: Unable to validate user from shore01/192.168.208.3:5672. Username:
> null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from B/192.168.208.3:5672. Username: null; SSL
> certificate subject DN: unavailable]
> {noformat}
> both the message and the exception show {{Username: null}}, which is not the
> given username.
> On the B side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from /192.168.208.2:38180. Username: ; SSL certificate
> subject DN: unavailable
> {noformat}
> this message shows the correct username.
> So the error message that gets returned from B to A is not the same and has
> less useful information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ARTEMIS-3150) wrong username in error message for AMQP connections
[
https://issues.apache.org/jira/browse/ARTEMIS-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic reassigned ARTEMIS-3150:
Assignee: Clebert Suconic
> wrong username in error message for AMQP connections
>
>
> Key: ARTEMIS-3150
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3150
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Assignee: Clebert Suconic
>Priority: Minor
> Attachments: A.log, B.log, brokerA.xml, brokerB.xml, login.config
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm connecting independent brokers A and B using the {{broker-connections}}
> mechanism. A connects to B.
> Using URI, NAME, USER and PASSWORD attributes. The password is wrong on
> purpose.
> On the A side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from B/192.168.208.3:5672. Username: null; SSL certificate
> subject DN: unavailable
> {noformat}
> which btw is immediately shown also as an exception:
> {noformat}
> AMQ229031: Unable to validate user from shore01/192.168.208.3:5672. Username:
> null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from B/192.168.208.3:5672. Username: null; SSL
> certificate subject DN: unavailable]
> {noformat}
> both the message and the exception show {{Username: null}}, which is not the
> given username.
> On the B side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from /192.168.208.2:38180. Username: ; SSL certificate
> subject DN: unavailable
> {noformat}
> this message shows the correct username.
> So the error message that gets returned from B to A is not the same and has
> less useful information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3150) wrong username in error message for AMQP connections
[
https://issues.apache.org/jira/browse/ARTEMIS-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3150.
Fix Version/s: 2.18.0
Resolution: Fixed
> wrong username in error message for AMQP connections
>
>
> Key: ARTEMIS-3150
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3150
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Assignee: Clebert Suconic
>Priority: Minor
> Fix For: 2.18.0
>
> Attachments: A.log, B.log, brokerA.xml, brokerB.xml, login.config
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm connecting independent brokers A and B using the {{broker-connections}}
> mechanism. A connects to B.
> Using URI, NAME, USER and PASSWORD attributes. The password is wrong on
> purpose.
> On the A side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from B/192.168.208.3:5672. Username: null; SSL certificate
> subject DN: unavailable
> {noformat}
> which btw is immediately shown also as an exception:
> {noformat}
> AMQ229031: Unable to validate user from shore01/192.168.208.3:5672. Username:
> null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from B/192.168.208.3:5672. Username: null; SSL
> certificate subject DN: unavailable]
> {noformat}
> both the message and the exception show {{Username: null}}, which is not the
> given username.
> On the B side, the error message is:
> {noformat}
> AMQ16: Security problem while authenticating: AMQ229031: Unable to
> validate user from /192.168.208.2:38180. Username: ; SSL certificate
> subject DN: unavailable
> {noformat}
> this message shows the correct username.
> So the error message that gets returned from B to A is not the same and has
> less useful information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3191) Cannot use broker-connection mirror with credentials
[
https://issues.apache.org/jira/browse/ARTEMIS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic updated ARTEMIS-3191:
-
Fix Version/s: 2.18.0
> Cannot use broker-connection mirror with credentials
>
>
> Key: ARTEMIS-3191
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3191
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
> Environment: Docker for MacOS
> Using the artemis-adoptopenjdk-11 image for Artemis 2.17.0
>Reporter: Stephen Baker
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.18.0
>
> Attachments: broker.xml, broker_1_m.xml, docker-compose.yml
>
>
> When using broker-connections with mirroring and username/password
> credentials (through PropertiesLoginModule required), messages do not make it
> to the fail over instance.
> I see the connection being established, the mirror queue is created, but
> fills up with more and more messages. There is a session on the replica
> server, but no session on the live server and no consumers in the mirror
> queue.
> On the live server I see the following in the log:
> {noformat}
> 2021-03-19 18:34:54,501 INFO
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111003:
> ***
> Success on Server AMQP Connection DRMirror1M on artemis-1-m:5672 after 0
> retries
> ***2021-03-19
> 18:34:54,820 WARN [org.apache.activemq.artemis.core.server] AMQ16:
> Security problem while authenticating: AMQ229031: Unable to validate user
> from artemis-1-m/172.18.0.2:5672. Username: null; SSL certificate subject DN:
> unavailable
> 2021-03-19 18:34:54,823 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ229031: Unable to validate user from artemis-1-m/172.18.0.2:5672.
> Username: null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from artemis-1-m/172.18.0.2:5672. Username: null; SSL
> certificate subject DN: unavailable]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:204)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1679)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.init(AMQPSessionCallback.java:210)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.initialize(AMQPSessionContext.java:81)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onLocalOpen(AMQPConnectionContext.java:567)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:47)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:564)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:359)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.flush(AMQPConnectionContext.java:234)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.connect.AMQPBrokerConnection.lambda$doConnect$2(AMQPBrokerConnection.java:259)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFact
[jira] [Assigned] (ARTEMIS-3191) Cannot use broker-connection mirror with credentials
[
https://issues.apache.org/jira/browse/ARTEMIS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic reassigned ARTEMIS-3191:
Assignee: Clebert Suconic
> Cannot use broker-connection mirror with credentials
>
>
> Key: ARTEMIS-3191
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3191
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
> Environment: Docker for MacOS
> Using the artemis-adoptopenjdk-11 image for Artemis 2.17.0
>Reporter: Stephen Baker
>Assignee: Clebert Suconic
>Priority: Major
> Attachments: broker.xml, broker_1_m.xml, docker-compose.yml
>
>
> When using broker-connections with mirroring and username/password
> credentials (through PropertiesLoginModule required), messages do not make it
> to the fail over instance.
> I see the connection being established, the mirror queue is created, but
> fills up with more and more messages. There is a session on the replica
> server, but no session on the live server and no consumers in the mirror
> queue.
> On the live server I see the following in the log:
> {noformat}
> 2021-03-19 18:34:54,501 INFO
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111003:
> ***
> Success on Server AMQP Connection DRMirror1M on artemis-1-m:5672 after 0
> retries
> ***2021-03-19
> 18:34:54,820 WARN [org.apache.activemq.artemis.core.server] AMQ16:
> Security problem while authenticating: AMQ229031: Unable to validate user
> from artemis-1-m/172.18.0.2:5672. Username: null; SSL certificate subject DN:
> unavailable
> 2021-03-19 18:34:54,823 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ229031: Unable to validate user from artemis-1-m/172.18.0.2:5672.
> Username: null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from artemis-1-m/172.18.0.2:5672. Username: null; SSL
> certificate subject DN: unavailable]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:204)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1679)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.init(AMQPSessionCallback.java:210)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.initialize(AMQPSessionContext.java:81)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onLocalOpen(AMQPConnectionContext.java:567)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:47)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:564)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:359)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.flush(AMQPConnectionContext.java:234)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.connect.AMQPBrokerConnection.lambda$doConnect$2(AMQPBrokerConnection.java:259)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [art
[jira] [Commented] (ARTEMIS-3191) Cannot use broker-connection mirror with credentials
[
https://issues.apache.org/jira/browse/ARTEMIS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306635#comment-17306635
]
Clebert Suconic commented on ARTEMIS-3191:
--
I'm testing this after the fix on ARTEMIS-3150.. I will have an update shortly.
> Cannot use broker-connection mirror with credentials
>
>
> Key: ARTEMIS-3191
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3191
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
> Environment: Docker for MacOS
> Using the artemis-adoptopenjdk-11 image for Artemis 2.17.0
>Reporter: Stephen Baker
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.18.0
>
> Attachments: broker.xml, broker_1_m.xml, docker-compose.yml
>
>
> When using broker-connections with mirroring and username/password
> credentials (through PropertiesLoginModule required), messages do not make it
> to the fail over instance.
> I see the connection being established, the mirror queue is created, but
> fills up with more and more messages. There is a session on the replica
> server, but no session on the live server and no consumers in the mirror
> queue.
> On the live server I see the following in the log:
> {noformat}
> 2021-03-19 18:34:54,501 INFO
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111003:
> ***
> Success on Server AMQP Connection DRMirror1M on artemis-1-m:5672 after 0
> retries
> ***2021-03-19
> 18:34:54,820 WARN [org.apache.activemq.artemis.core.server] AMQ16:
> Security problem while authenticating: AMQ229031: Unable to validate user
> from artemis-1-m/172.18.0.2:5672. Username: null; SSL certificate subject DN:
> unavailable
> 2021-03-19 18:34:54,823 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ229031: Unable to validate user from artemis-1-m/172.18.0.2:5672.
> Username: null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from artemis-1-m/172.18.0.2:5672. Username: null; SSL
> certificate subject DN: unavailable]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:204)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1679)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.init(AMQPSessionCallback.java:210)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.initialize(AMQPSessionContext.java:81)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onLocalOpen(AMQPConnectionContext.java:567)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:47)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:564)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:359)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.flush(AMQPConnectionContext.java:234)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.connect.AMQPBrokerConnection.lambda$doConnect$2(AMQPBrokerConnection.java:259)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-all-4.1.51.Final.ja
[jira] [Work logged] (ARTEMIS-3191) Cannot use broker-connection mirror with credentials
[
https://issues.apache.org/jira/browse/ARTEMIS-3191?focusedWorklogId=570127&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570127
]
ASF GitHub Bot logged work on ARTEMIS-3191:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 23:02
Start Date: 22/Mar/21 23:02
Worklog Time Spent: 10m
Work Description: clebertsuconic opened a new pull request #3511:
URL: https://github.com/apache/activemq-artemis/pull/3511
--
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: 570127)
Remaining Estimate: 0h
Time Spent: 10m
> Cannot use broker-connection mirror with credentials
>
>
> Key: ARTEMIS-3191
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3191
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
> Environment: Docker for MacOS
> Using the artemis-adoptopenjdk-11 image for Artemis 2.17.0
>Reporter: Stephen Baker
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.18.0
>
> Attachments: broker.xml, broker_1_m.xml, docker-compose.yml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using broker-connections with mirroring and username/password
> credentials (through PropertiesLoginModule required), messages do not make it
> to the fail over instance.
> I see the connection being established, the mirror queue is created, but
> fills up with more and more messages. There is a session on the replica
> server, but no session on the live server and no consumers in the mirror
> queue.
> On the live server I see the following in the log:
> {noformat}
> 2021-03-19 18:34:54,501 INFO
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111003:
> ***
> Success on Server AMQP Connection DRMirror1M on artemis-1-m:5672 after 0
> retries
> ***2021-03-19
> 18:34:54,820 WARN [org.apache.activemq.artemis.core.server] AMQ16:
> Security problem while authenticating: AMQ229031: Unable to validate user
> from artemis-1-m/172.18.0.2:5672. Username: null; SSL certificate subject DN:
> unavailable
> 2021-03-19 18:34:54,823 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ229031: Unable to validate user from artemis-1-m/172.18.0.2:5672.
> Username: null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from artemis-1-m/172.18.0.2:5672. Username: null; SSL
> certificate subject DN: unavailable]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:204)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1679)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.init(AMQPSessionCallback.java:210)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.initialize(AMQPSessionContext.java:81)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onLocalOpen(AMQPConnectionContext.java:567)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:47)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:564)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:359)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.flush(AMQPConnectionContext.java:234)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.connect.AMQPBrokerConnection.lambda$doConnect$2(AMQPBrokerConnection.java:259)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> io.netty.util.concurrent.AbstractEventExe
[jira] [Closed] (ARTEMIS-3191) Cannot use broker-connection mirror with credentials
[
https://issues.apache.org/jira/browse/ARTEMIS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3191.
Resolution: Fixed
> Cannot use broker-connection mirror with credentials
>
>
> Key: ARTEMIS-3191
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3191
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
> Environment: Docker for MacOS
> Using the artemis-adoptopenjdk-11 image for Artemis 2.17.0
>Reporter: Stephen Baker
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.18.0
>
> Attachments: broker.xml, broker_1_m.xml, docker-compose.yml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using broker-connections with mirroring and username/password
> credentials (through PropertiesLoginModule required), messages do not make it
> to the fail over instance.
> I see the connection being established, the mirror queue is created, but
> fills up with more and more messages. There is a session on the replica
> server, but no session on the live server and no consumers in the mirror
> queue.
> On the live server I see the following in the log:
> {noformat}
> 2021-03-19 18:34:54,501 INFO
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111003:
> ***
> Success on Server AMQP Connection DRMirror1M on artemis-1-m:5672 after 0
> retries
> ***2021-03-19
> 18:34:54,820 WARN [org.apache.activemq.artemis.core.server] AMQ16:
> Security problem while authenticating: AMQ229031: Unable to validate user
> from artemis-1-m/172.18.0.2:5672. Username: null; SSL certificate subject DN:
> unavailable
> 2021-03-19 18:34:54,823 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ229031: Unable to validate user from artemis-1-m/172.18.0.2:5672.
> Username: null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from artemis-1-m/172.18.0.2:5672. Username: null; SSL
> certificate subject DN: unavailable]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:204)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1679)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.init(AMQPSessionCallback.java:210)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.initialize(AMQPSessionContext.java:81)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onLocalOpen(AMQPConnectionContext.java:567)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:47)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:564)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:359)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.flush(AMQPConnectionContext.java:234)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.connect.AMQPBrokerConnection.lambda$doConnect$2(AMQPBrokerConnection.java:259)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> org.apache.activemq.artemis.utils
[jira] [Commented] (ARTEMIS-3191) Cannot use broker-connection mirror with credentials
[
https://issues.apache.org/jira/browse/ARTEMIS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306637#comment-17306637
]
Clebert Suconic commented on ARTEMIS-3191:
--
I confirm the issue is fixed after ARTEMIS-3150. I am adding a test to validate
this specific use case though (with mirror)
> Cannot use broker-connection mirror with credentials
>
>
> Key: ARTEMIS-3191
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3191
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
> Environment: Docker for MacOS
> Using the artemis-adoptopenjdk-11 image for Artemis 2.17.0
>Reporter: Stephen Baker
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.18.0
>
> Attachments: broker.xml, broker_1_m.xml, docker-compose.yml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using broker-connections with mirroring and username/password
> credentials (through PropertiesLoginModule required), messages do not make it
> to the fail over instance.
> I see the connection being established, the mirror queue is created, but
> fills up with more and more messages. There is a session on the replica
> server, but no session on the live server and no consumers in the mirror
> queue.
> On the live server I see the following in the log:
> {noformat}
> 2021-03-19 18:34:54,501 INFO
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111003:
> ***
> Success on Server AMQP Connection DRMirror1M on artemis-1-m:5672 after 0
> retries
> ***2021-03-19
> 18:34:54,820 WARN [org.apache.activemq.artemis.core.server] AMQ16:
> Security problem while authenticating: AMQ229031: Unable to validate user
> from artemis-1-m/172.18.0.2:5672. Username: null; SSL certificate subject DN:
> unavailable
> 2021-03-19 18:34:54,823 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ229031: Unable to validate user from artemis-1-m/172.18.0.2:5672.
> Username: null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from artemis-1-m/172.18.0.2:5672. Username: null; SSL
> certificate subject DN: unavailable]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:204)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1679)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.init(AMQPSessionCallback.java:210)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.initialize(AMQPSessionContext.java:81)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onLocalOpen(AMQPConnectionContext.java:567)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:47)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:564)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:359)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.flush(AMQPConnectionContext.java:234)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.connect.AMQPBrokerConnection.lambda$doConnect$2(AMQPBrokerConnection.java:259)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.ne
[jira] [Commented] (ARTEMIS-3191) Cannot use broker-connection mirror with credentials
[
https://issues.apache.org/jira/browse/ARTEMIS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306639#comment-17306639
]
ASF subversion and git services commented on ARTEMIS-3191:
--
Commit 41d9eef511d95aaa6475b91f89da09418b40e957 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=41d9eef ]
ARTEMIS-3191 Tests with Mirror and Credentials
> Cannot use broker-connection mirror with credentials
>
>
> Key: ARTEMIS-3191
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3191
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.17.0
> Environment: Docker for MacOS
> Using the artemis-adoptopenjdk-11 image for Artemis 2.17.0
>Reporter: Stephen Baker
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.18.0
>
> Attachments: broker.xml, broker_1_m.xml, docker-compose.yml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using broker-connections with mirroring and username/password
> credentials (through PropertiesLoginModule required), messages do not make it
> to the fail over instance.
> I see the connection being established, the mirror queue is created, but
> fills up with more and more messages. There is a session on the replica
> server, but no session on the live server and no consumers in the mirror
> queue.
> On the live server I see the following in the log:
> {noformat}
> 2021-03-19 18:34:54,501 INFO
> [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111003:
> ***
> Success on Server AMQP Connection DRMirror1M on artemis-1-m:5672 after 0
> retries
> ***2021-03-19
> 18:34:54,820 WARN [org.apache.activemq.artemis.core.server] AMQ16:
> Security problem while authenticating: AMQ229031: Unable to validate user
> from artemis-1-m/172.18.0.2:5672. Username: null; SSL certificate subject DN:
> unavailable
> 2021-03-19 18:34:54,823 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ229031: Unable to validate user from artemis-1-m/172.18.0.2:5672.
> Username: null; SSL certificate subject DN: unavailable:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ229031:
> Unable to validate user from artemis-1-m/172.18.0.2:5672. Username: null; SSL
> certificate subject DN: unavailable]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:204)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1679)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.init(AMQPSessionCallback.java:210)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.initialize(AMQPSessionContext.java:81)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onLocalOpen(AMQPConnectionContext.java:567)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:47)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:564)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:359)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.flush(AMQPConnectionContext.java:234)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.protocol.amqp.connect.AMQPBrokerConnection.lambda$doConnect$2(AMQPBrokerConnection.java:259)
> [artemis-amqp-protocol-2.17.0.jar:2.17.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
> [netty-all-4.1.51.Final.jar:4.1.51.Final]
> at
> io.netty.util
[jira] [Work logged] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=570133&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570133 ] ASF GitHub Bot logged work on ARTEMIS-3198: --- Author: ASF GitHub Bot Created on: 22/Mar/21 23:13 Start Date: 22/Mar/21 23:13 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3509: URL: https://github.com/apache/activemq-artemis/pull/3509 -- 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: 570133) Time Spent: 1h (was: 50m) > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306640#comment-17306640 ] ASF subversion and git services commented on ARTEMIS-3198: -- Commit e9e1e476ee210b69b4b8cebed759b9103b37b7ab in activemq-artemis's branch refs/heads/master from AntonRoskvist [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e9e1e47 ] ARTEMIS-3198 Add concurrency option on core bridges > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3197) Add selectorAware option to the openwire virtualTopicConsumerWildcards feature
[
https://issues.apache.org/jira/browse/ARTEMIS-3197?focusedWorklogId=570135&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570135
]
ASF GitHub Bot logged work on ARTEMIS-3197:
---
Author: ASF GitHub Bot
Created on: 22/Mar/21 23:14
Start Date: 22/Mar/21 23:14
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3508:
URL: https://github.com/apache/activemq-artemis/pull/3508#discussion_r599136365
##
File path:
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/openwire/VirtualTopicToFQQNOpenWireTest.java
##
@@ -222,4 +227,59 @@ public void testAutoVirtualTopicWildcardStarFQQN() throws
Exception {
}
}
}
+
+
+ @Test
Review comment:
Nice one
--
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: 570135)
Time Spent: 20m (was: 10m)
> Add selectorAware option to the openwire virtualTopicConsumerWildcards feature
> --
>
> Key: ARTEMIS-3197
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3197
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: OpenWire
>Affects Versions: 2.17.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.18.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [VirtualTopics|https://activemq.apache.org/virtual-destinations.html] support
> the selector aware option, which filters messages at the point of fanout
> based on the consumers selector.
> queues have the option to filter messages, with auto creation, the selector
> from the openwire consumers info can be used to apply a queue filter.
> Unmatched messages are not routed in this case.
> Unlike classic virtual topics, the selector/filter is persisted by default
> and there is no need for the selector cache plugin.
> The virtualTopicConsumerWildcards configuration for the openwire acceptor
> needs an optional selectorAware parameter to support this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3197) Add selectorAware option to the openwire virtualTopicConsumerWildcards feature
[ https://issues.apache.org/jira/browse/ARTEMIS-3197?focusedWorklogId=570136&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570136 ] ASF GitHub Bot logged work on ARTEMIS-3197: --- Author: ASF GitHub Bot Created on: 22/Mar/21 23:15 Start Date: 22/Mar/21 23:15 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3508: URL: https://github.com/apache/activemq-artemis/pull/3508 -- 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: 570136) Time Spent: 0.5h (was: 20m) > Add selectorAware option to the openwire virtualTopicConsumerWildcards feature > -- > > Key: ARTEMIS-3197 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3197 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > [VirtualTopics|https://activemq.apache.org/virtual-destinations.html] support > the selector aware option, which filters messages at the point of fanout > based on the consumers selector. > queues have the option to filter messages, with auto creation, the selector > from the openwire consumers info can be used to apply a queue filter. > Unmatched messages are not routed in this case. > Unlike classic virtual topics, the selector/filter is persisted by default > and there is no need for the selector cache plugin. > The virtualTopicConsumerWildcards configuration for the openwire acceptor > needs an optional selectorAware parameter to support this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3197) Add selectorAware option to the openwire virtualTopicConsumerWildcards feature
[ https://issues.apache.org/jira/browse/ARTEMIS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306641#comment-17306641 ] ASF subversion and git services commented on ARTEMIS-3197: -- Commit 8fd1b33d1638c1232197d5399c23daadee491289 in activemq-artemis's branch refs/heads/master from gtully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8fd1b33 ] ARTEMIS-3197 - add selectorAware option to virtualTopicConsumerWildcards for openwire acceptor > Add selectorAware option to the openwire virtualTopicConsumerWildcards feature > -- > > Key: ARTEMIS-3197 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3197 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 20m > Remaining Estimate: 0h > > [VirtualTopics|https://activemq.apache.org/virtual-destinations.html] support > the selector aware option, which filters messages at the point of fanout > based on the consumers selector. > queues have the option to filter messages, with auto creation, the selector > from the openwire consumers info can be used to apply a queue filter. > Unmatched messages are not routed in this case. > Unlike classic virtual topics, the selector/filter is persisted by default > and there is no need for the selector cache plugin. > The virtualTopicConsumerWildcards configuration for the openwire acceptor > needs an optional selectorAware parameter to support this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (ARTEMIS-3157) uneven number of connections in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3157: --- Comment: was deleted (was: relation with ARTEMIS-2870? my answer: NO, ARTEMIS-2870 has been solved and the effect is still visible) > uneven number of connections in a cluster > - > > Key: ARTEMIS-3157 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3157 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.17.0 >Reporter: Erwin Dondorp >Priority: Minor > > Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a > fresh virtual disk. > On each master nodes, the 2 static connections to the other master nodes are > visible, and each is marked with the dedicated cluster username. so that part > seems ok. > but without any clients having connected, there are additional connections. > the amount is not the same in each master node. Some connections show > "127.0.0.1" as address, something that is not in my configuration. none of > the extra connections have any sessions. > the details of an example: > * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra > to/from backup of broker3 > * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra > to/from broker3; 1 extra to/from slave of broker3 > * broker3: 1 connection to own slave; no other extra connections > the exact amount of connections varies a little between startups and also > seems to depend on the exact startup sequence. > my assumption is that these connections should not be present, and that this > is not intended, hence this report. my wild guess is that these are remnants > from connections that did not success due to the cluster not fully available > yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-3157) uneven number of connections in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303775#comment-17303775 ] Erwin Dondorp edited comment on ARTEMIS-3157 at 3/23/21, 1:50 AM: -- relation with ARTEMIS-2870? my answer: NO, ARTEMIS-2870 has been solved and the effect is still visible was (Author: erwindon): relation with ARTEMIS-2870? > uneven number of connections in a cluster > - > > Key: ARTEMIS-3157 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3157 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.17.0 >Reporter: Erwin Dondorp >Priority: Minor > > Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a > fresh virtual disk. > On each master nodes, the 2 static connections to the other master nodes are > visible, and each is marked with the dedicated cluster username. so that part > seems ok. > but without any clients having connected, there are additional connections. > the amount is not the same in each master node. Some connections show > "127.0.0.1" as address, something that is not in my configuration. none of > the extra connections have any sessions. > the details of an example: > * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra > to/from backup of broker3 > * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra > to/from broker3; 1 extra to/from slave of broker3 > * broker3: 1 connection to own slave; no other extra connections > the exact amount of connections varies a little between startups and also > seems to depend on the exact startup sequence. > my assumption is that these connections should not be present, and that this > is not intended, hence this report. my wild guess is that these are remnants > from connections that did not success due to the cluster not fully available > yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3157) uneven number of connections in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3157: --- Priority: Major (was: Minor) > uneven number of connections in a cluster > - > > Key: ARTEMIS-3157 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3157 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.17.0 >Reporter: Erwin Dondorp >Priority: Major > > Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a > fresh virtual disk. > On each master nodes, the 2 static connections to the other master nodes are > visible, and each is marked with the dedicated cluster username. so that part > seems ok. > but without any clients having connected, there are additional connections. > the amount is not the same in each master node. Some connections show > "127.0.0.1" as address, something that is not in my configuration. none of > the extra connections have any sessions. > the details of an example: > * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra > to/from backup of broker3 > * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra > to/from broker3; 1 extra to/from slave of broker3 > * broker3: 1 connection to own slave; no other extra connections > the exact amount of connections varies a little between startups and also > seems to depend on the exact startup sequence. > my assumption is that these connections should not be present, and that this > is not intended, hence this report. my wild guess is that these are remnants > from connections that did not success due to the cluster not fully available > yet. > When the cluster is started one node at a time, the effect seems to exists > only on the first node that was started. > Note: not related to ARTEMIS-2870 as this report is till valid in > 2.18.0-20210322.234647-43. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3157) uneven number of connections in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3157: --- Description: Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a fresh virtual disk. On each master nodes, the 2 static connections to the other master nodes are visible, and each is marked with the dedicated cluster username. so that part seems ok. but without any clients having connected, there are additional connections. the amount is not the same in each master node. Some connections show "127.0.0.1" as address, something that is not in my configuration. none of the extra connections have any sessions. the details of an example: * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from backup of broker3 * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from broker3; 1 extra to/from slave of broker3 * broker3: 1 connection to own slave; no other extra connections the exact amount of connections varies a little between startups and also seems to depend on the exact startup sequence. my assumption is that these connections should not be present, and that this is not intended, hence this report. my wild guess is that these are remnants from connections that did not success due to the cluster not fully available yet. When the cluster is started one node at a time, the effect seems to exists only on the first node that was started. Note: not related to ARTEMIS-2870 as this report is till valid in 2.18.0-20210322.234647-43. was: Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a fresh virtual disk. On each master nodes, the 2 static connections to the other master nodes are visible, and each is marked with the dedicated cluster username. so that part seems ok. but without any clients having connected, there are additional connections. the amount is not the same in each master node. Some connections show "127.0.0.1" as address, something that is not in my configuration. none of the extra connections have any sessions. the details of an example: * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from backup of broker3 * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from broker3; 1 extra to/from slave of broker3 * broker3: 1 connection to own slave; no other extra connections the exact amount of connections varies a little between startups and also seems to depend on the exact startup sequence. my assumption is that these connections should not be present, and that this is not intended, hence this report. my wild guess is that these are remnants from connections that did not success due to the cluster not fully available yet. > uneven number of connections in a cluster > - > > Key: ARTEMIS-3157 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3157 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.17.0 >Reporter: Erwin Dondorp >Priority: Minor > > Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a > fresh virtual disk. > On each master nodes, the 2 static connections to the other master nodes are > visible, and each is marked with the dedicated cluster username. so that part > seems ok. > but without any clients having connected, there are additional connections. > the amount is not the same in each master node. Some connections show > "127.0.0.1" as address, something that is not in my configuration. none of > the extra connections have any sessions. > the details of an example: > * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra > to/from backup of broker3 > * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra > to/from broker3; 1 extra to/from slave of broker3 > * broker3: 1 connection to own slave; no other extra connections > the exact amount of connections varies a little between startups and also > seems to depend on the exact startup sequence. > my assumption is that these connections should not be present, and that this > is not intended, hence this report. my wild guess is that these are remnants > from connections that did not success due to the cluster not fully available > yet. > When the cluster is started one node at a time, the effect seems to exists > only on the first node that was started. > Note: not related to ARTEMIS-2870 as this report is till valid in > 2.18.0-20210322.234647-43. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3198) Add ability to increase concurrency on core bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306688#comment-17306688 ] ASF subversion and git services commented on ARTEMIS-3198: -- Commit 31345c5b51c1d8fd309708128eb160382c0c3f34 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=31345c5 ] ARTEMIS-3198 Fixing test after concurrency bridge changes > Add ability to increase concurrency on core bridges > --- > > Key: ARTEMIS-3198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3198 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Anton Roskvist >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > Add ability to increase concurrency on core bridges. This is useful for > deploying bridges over high latency networks when the message volume is high. > More concurrency allows for increased throughput. > > I have run some tests locally, sending 20k messages across a WAN link. Using > the default setting I was able to move all messages from point A to point B > in: 2m5s31ms > Adding another bridge, with identical parameters besides the name, the same > 20k messages where moved in: 1min6s14ms > Adding a third means: 33s.19ms > So this is pretty much linear increase in throughput based on the number of > bridges configured for the same destination. This works, but if multiple > queues and destinations are involved the config file gets quite messy. > Therefor I propose the addition of a concurrency property for these bridges, > which basically spawns N amount of bridges behind the scenes instead, keeping > the config file nice and tidy and the messages flying. > Test summary: > 20k messages (identical across runs), point A to point B over WAN: > 1 bridge : 2m 5s 31ms > 2 bridges: 1m 6s 14ms > 3 bridges: 33s 19ms > Br, > Anton -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3157) uneven number of connections in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3157: --- Description: Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a fresh virtual disk. On each master nodes, the 2 static connections to the other master nodes are visible, and each is marked with the dedicated cluster username. so that part seems ok. but without any clients having connected, there are additional connections. the amount is not the same in each master node. Some connections show "127.0.0.1" as address, something that is not in my configuration. none of the extra connections have any sessions. the details of an example: * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from backup of broker3 * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from broker3; 1 extra to/from slave of broker3 * broker3: 1 connection to own slave; no other extra connections the exact amount of connections varies a little between startups and also seems to depend on the exact startup sequence. my assumption is that these connections should not be present, and that this is not intended, hence this report. my wild guess is that these are remnants from connections that did not success due to the cluster not fully available yet. When the cluster is started one node at a time, the effect seems to exists only on the first node that was started. Note: not related to ARTEMIS-2870 as this report is still valid in 2.18.0-20210322.234647-43. was: Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a fresh virtual disk. On each master nodes, the 2 static connections to the other master nodes are visible, and each is marked with the dedicated cluster username. so that part seems ok. but without any clients having connected, there are additional connections. the amount is not the same in each master node. Some connections show "127.0.0.1" as address, something that is not in my configuration. none of the extra connections have any sessions. the details of an example: * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from backup of broker3 * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from broker3; 1 extra to/from slave of broker3 * broker3: 1 connection to own slave; no other extra connections the exact amount of connections varies a little between startups and also seems to depend on the exact startup sequence. my assumption is that these connections should not be present, and that this is not intended, hence this report. my wild guess is that these are remnants from connections that did not success due to the cluster not fully available yet. When the cluster is started one node at a time, the effect seems to exists only on the first node that was started. Note: not related to ARTEMIS-2870 as this report is till valid in 2.18.0-20210322.234647-43. > uneven number of connections in a cluster > - > > Key: ARTEMIS-3157 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3157 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.17.0 >Reporter: Erwin Dondorp >Priority: Major > > Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a > fresh virtual disk. > On each master nodes, the 2 static connections to the other master nodes are > visible, and each is marked with the dedicated cluster username. so that part > seems ok. > but without any clients having connected, there are additional connections. > the amount is not the same in each master node. Some connections show > "127.0.0.1" as address, something that is not in my configuration. none of > the extra connections have any sessions. > the details of an example: > * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra > to/from backup of broker3 > * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra > to/from broker3; 1 extra to/from slave of broker3 > * broker3: 1 connection to own slave; no other extra connections > the exact amount of connections varies a little between startups and also > seems to depend on the exact startup sequence. > my assumption is that these connections should not be present, and that this > is not intended, hence this report. my wild guess is that these are remnants > from connections that did not success due to the cluster not fully available > yet. > When the cluster is started one node at a time, the effect seems to exists > only on the first node that was started. > Note: not related to ARTEMIS-2870 as this report is still valid in > 2.18.0-20210322.234647-43. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3157) uneven number of connections in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3157: --- Description: Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a fresh virtual disk. no other constructions (bridges/federation/brokerconn/etc) and also no clients. On each master nodes, the 2 static connections to the other master nodes are visible, and each is marked with the dedicated cluster username. so that part seems ok. but without any clients having connected, there are additional connections. the amount is not the same in each master node. Some connections show "127.0.0.1" as address, something that is not in my configuration. none of the extra connections have any sessions. the details of an example: * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from backup of broker3 * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from broker3; 1 extra to/from slave of broker3 * broker3: 1 connection to own slave; no other extra connections the exact amount of connections varies a little between startups and also seems to depend on the exact startup sequence. my assumption is that these connections should not be present, and that this is not intended, hence this report. my wild guess is that these are remnants from connections that did not success due to the cluster not fully available yet. When the cluster is started one node at a time, the effect seems to exists only on the first node that was started. Note: not related to ARTEMIS-2870 as this report is still valid in 2.18.0-20210322.234647-43. was: Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a fresh virtual disk. On each master nodes, the 2 static connections to the other master nodes are visible, and each is marked with the dedicated cluster username. so that part seems ok. but without any clients having connected, there are additional connections. the amount is not the same in each master node. Some connections show "127.0.0.1" as address, something that is not in my configuration. none of the extra connections have any sessions. the details of an example: * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra to/from backup of broker3 * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra to/from broker3; 1 extra to/from slave of broker3 * broker3: 1 connection to own slave; no other extra connections the exact amount of connections varies a little between startups and also seems to depend on the exact startup sequence. my assumption is that these connections should not be present, and that this is not intended, hence this report. my wild guess is that these are remnants from connections that did not success due to the cluster not fully available yet. When the cluster is started one node at a time, the effect seems to exists only on the first node that was started. Note: not related to ARTEMIS-2870 as this report is still valid in 2.18.0-20210322.234647-43. > uneven number of connections in a cluster > - > > Key: ARTEMIS-3157 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3157 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.17.0 >Reporter: Erwin Dondorp >Priority: Major > > Using a cluster of 3 master + 3 slave nodes. full interconnect, each with a > fresh virtual disk. no other constructions > (bridges/federation/brokerconn/etc) and also no clients. > On each master nodes, the 2 static connections to the other master nodes are > visible, and each is marked with the dedicated cluster username. so that part > seems ok. > but without any clients having connected, there are additional connections. > the amount is not the same in each master node. Some connections show > "127.0.0.1" as address, something that is not in my configuration. none of > the extra connections have any sessions. > the details of an example: > * broker1: 3 connections to own slave; 2 extra to/from broker2; 1 extra > to/from backup of broker3 > * broker2: 3 connections to own slave; 2 extra to/from broker1; 2 extra > to/from broker3; 1 extra to/from slave of broker3 > * broker3: 1 connection to own slave; no other extra connections > the exact amount of connections varies a little between startups and also > seems to depend on the exact startup sequence. > my assumption is that these connections should not be present, and that this > is not intended, hence this report. my wild guess is that these are remnants > from connections that did not success due to the cluster not fully available > yet. > When the cluster is started one node at a time, the effect seems to exists > only on the first node that was started
[jira] [Work logged] (ARTEMIS-3195) Filter empty items from listNetworkTopology
[ https://issues.apache.org/jira/browse/ARTEMIS-3195?focusedWorklogId=570192&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570192 ] ASF GitHub Bot logged work on ARTEMIS-3195: --- Author: ASF GitHub Bot Created on: 23/Mar/21 02:20 Start Date: 23/Mar/21 02:20 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3505: URL: https://github.com/apache/activemq-artemis/pull/3505 -- 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: 570192) Time Spent: 20m (was: 10m) > Filter empty items from listNetworkTopology > --- > > Key: ARTEMIS-3195 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3195 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Sometimes the listNetworkTopology temporarily returns an empty item. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3195) Filter empty items from listNetworkTopology
[ https://issues.apache.org/jira/browse/ARTEMIS-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306697#comment-17306697 ] ASF subversion and git services commented on ARTEMIS-3195: -- Commit 4473758edb400e1f815e13c33431d189e39610df in activemq-artemis's branch refs/heads/master from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4473758 ] ARTEMIS-3195 Filter empty items from listNetworkTopology > Filter empty items from listNetworkTopology > --- > > Key: ARTEMIS-3195 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3195 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes the listNetworkTopology temporarily returns an empty item. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3106) Support for SASL-SCRAM
[ https://issues.apache.org/jira/browse/ARTEMIS-3106?focusedWorklogId=570252&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570252 ] ASF GitHub Bot logged work on ARTEMIS-3106: --- Author: ASF GitHub Bot Created on: 23/Mar/21 06:15 Start Date: 23/Mar/21 06:15 Worklog Time Spent: 10m Work Description: laeubi commented on a change in pull request #3470: URL: https://github.com/apache/activemq-artemis/pull/3470#discussion_r599295293 ## File path: tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/connect/SaslScramTest.java ## @@ -0,0 +1,87 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.activemq.artemis.tests.integration.amqp.connect; Review comment: Is there any example in Artemis using AMQP+SASL (plain) for inter broker communication I could use to check this case? -- 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: 570252) Time Spent: 10h 10m (was: 10h) > Support for SASL-SCRAM > -- > > Key: ARTEMIS-3106 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3106 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP >Reporter: Christoph Läubrich >Priority: Major > Time Spent: 10h 10m > Remaining Estimate: 0h > > With the enhancements in ARTEMIS-33 / [PR > 3432|https://github.com/apache/activemq-artemis/pull/3432] it would be now > possible to plug-in new SASL mechanism. > One popular one is > [SASL-SCRAM|https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism] > because it allows channelbinding together with secure storage of > user-credential. > I have created an [implementation of this for Artemis > AMQP|https://github.com/laeubi/scram-sasl/tree/artemis/artemis] based on the > [SCRAM SASL authentication for Java|https://github.com/ogrebgr/scram-sasl] > code with some enhancements/cleanups to the original. > As the source is already Apache licensed I'd like to propose to include this > in the Artemis code-base. This would greatly enhance the interoperability > with other implementations e.g. Apache QPID. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3106) Support for SASL-SCRAM
[
https://issues.apache.org/jira/browse/ARTEMIS-3106?focusedWorklogId=570259&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570259
]
ASF GitHub Bot logged work on ARTEMIS-3106:
---
Author: ASF GitHub Bot
Created on: 23/Mar/21 06:23
Start Date: 23/Mar/21 06:23
Worklog Time Spent: 10m
Work Description: laeubi commented on a change in pull request #3470:
URL: https://github.com/apache/activemq-artemis/pull/3470#discussion_r599298651
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/SCRAMPropertiesLoginModule.java
##
@@ -0,0 +1,202 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.spi.core.security.jaas;
+
+import java.io.IOException;
+import java.security.GeneralSecurityException;
+import java.security.MessageDigest;
+import java.security.Principal;
+import java.security.SecureRandom;
+import java.util.Arrays;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.Properties;
+import java.util.Set;
+
+import javax.crypto.Mac;
+import javax.security.auth.Subject;
+import javax.security.auth.callback.Callback;
+import javax.security.auth.callback.CallbackHandler;
+import javax.security.auth.callback.NameCallback;
+import javax.security.auth.callback.UnsupportedCallbackException;
+import javax.security.auth.login.FailedLoginException;
+import javax.security.auth.login.LoginException;
+
+import org.apache.activemq.artemis.spi.core.security.scram.SCRAM;
+import org.apache.activemq.artemis.spi.core.security.scram.ScramException;
+import org.apache.activemq.artemis.spi.core.security.scram.ScramUtils;
+import org.apache.activemq.artemis.spi.core.security.scram.UserData;
+import org.apache.activemq.artemis.utils.PasswordMaskingUtil;
+
+/**
+ * Login modules that uses properties files similar to the {@link
PropertiesLoginModule}. It can
+ * either store the username-password in plain text or in an encrypted/hashed
form. the
+ * {@link #main(String[])} method provides a way to prepare unencrypted data
to be encrypted/hashed.
+ */
+public class SCRAMPropertiesLoginModule extends PropertiesLoader implements
AuditLoginModule {
+
+ private static final String SEPARATOR = ":";
+ private static final int MIN_ITERATIONS = 4096;
+ private Subject subject;
+ private CallbackHandler callbackHandler;
+ private Properties users;
+ private Map> roles;
+ private UserData userData;
+ private String user;
+ private final Set principals = new HashSet<>();
+
+ @Override
+ public void initialize(Subject subject, CallbackHandler callbackHandler,
Map sharedState,
+ Map options) {
+ this.subject = subject;
+ this.callbackHandler = callbackHandler;
+
+ init(options);
+ users = load(PropertiesLoginModule.USER_FILE_PROP_NAME, "user",
options).getProps();
+ roles = load(PropertiesLoginModule.ROLE_FILE_PROP_NAME, "role",
options).invertedPropertiesValuesMap();
+
+ }
+
+ @Override
+ public boolean login() throws LoginException {
+ NameCallback nameCallback = new NameCallback("Username: ");
+ executeCallbacks(new Callback[] {nameCallback});
+ user = nameCallback.getName();
+ if (user == null) {
+ throw new FailedLoginException("User is null");
+ }
+ String password = users.getProperty(user);
+ if (password == null) {
+ throw new FailedLoginException("User does not exist: " + user);
+ }
+ if (PasswordMaskingUtil.isEncMasked(password)) {
+ String[] unwrap =
PasswordMaskingUtil.unwrap(password).split(SEPARATOR);
+ userData = new UserData(unwrap[0], Integer.parseInt(unwrap[1]),
unwrap[2], unwrap[3]);
+ } else {
+ DigestCallback digestCallback = new DigestCallback();
+ HmacCallback hmacCallback = new HmacCallback();
+ executeCallbacks(new Callback[] {digestCallback, hmacCallback});
+ byte[] salt = generateSalt();
+ try {
+ScramUtils.NewPasswordStringData data =
+
ScramUtils.byteArrayToStringData(ScramUtils.newPassword(p
[jira] [Work logged] (ARTEMIS-3106) Support for SASL-SCRAM
[
https://issues.apache.org/jira/browse/ARTEMIS-3106?focusedWorklogId=570261&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570261
]
ASF GitHub Bot logged work on ARTEMIS-3106:
---
Author: ASF GitHub Bot
Created on: 23/Mar/21 06:26
Start Date: 23/Mar/21 06:26
Worklog Time Spent: 10m
Work Description: laeubi commented on a change in pull request #3470:
URL: https://github.com/apache/activemq-artemis/pull/3470#discussion_r599299927
##
File path:
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/sasl/SaslScramTest.java
##
@@ -0,0 +1,94 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.tests.integration.amqp.sasl;
+
+import static org.junit.Assert.assertEquals;
+
+import java.io.File;
+
+import javax.jms.Connection;
+import javax.jms.ConnectionFactory;
+import javax.jms.JMSException;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageProducer;
+import javax.jms.Queue;
+import javax.jms.Session;
+import javax.jms.TextMessage;
+
+import org.apache.activemq.artemis.core.server.embedded.EmbeddedActiveMQ;
+import
org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager;
+import org.apache.qpid.jms.JmsConnectionFactory;
+import org.apache.qpid.jms.exceptions.JMSSecuritySaslException;
+import org.junit.AfterClass;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+/**
+ * This test SASL-SCRAM Support
+ */
+public class SaslScramTest {
+
+ private static EmbeddedActiveMQ BROKER;
+
+ @BeforeClass
+ public static void startBroker() throws Exception {
+ String loginConfPath = new
File(SaslScramTest.class.getResource("/login.config").toURI()).getAbsolutePath();
+ System.out.println(loginConfPath);
+ System.setProperty("java.security.auth.login.config", loginConfPath);
+ BROKER = new EmbeddedActiveMQ();
+
BROKER.setConfigResourcePath(SaslScramTest.class.getResource("/broker-saslscram.xml").toExternalForm());
+ BROKER.setSecurityManager(new
ActiveMQJAASSecurityManager("artemis-sasl-scram"));
+ BROKER.start();
+ }
+
+ @AfterClass
+ public static void shutdownBroker() throws Exception {
+ BROKER.stop();
+ }
+
+ @Test
+ public void testUnencryptedWorksWithAllMechanism() throws JMSException {
+ sendRcv("SCRAM-SHA-1", "hello", "ogre1234");
+ sendRcv("SCRAM-SHA-256", "hello", "ogre1234");
+ }
+
+ @Test(expected = JMSSecuritySaslException.class)
+ public void testEncryptedWorksOnlyWithMechanism() throws JMSException {
+ sendRcv("SCRAM-SHA-1", "test", "test");
+ }
+
+ @Test
+ public void testEncryptedWorksWithMechanism() throws JMSException {
+ sendRcv("SCRAM-SHA-256", "test", "test");
+ }
Review comment:
btw the spec says:
> For interoperability, all SCRAM clients and servers MUST implement
>the SCRAM-SHA-1 authentication mechanism, i.e., an authentication
>mechanism from the SCRAM family that uses the SHA-1 hash function as
>defined in [RFC3174].
so removing SHA-1 seems to be not an option if we want compliance with the
spec.
About different schemes, the spec mandates that
> Authentication information: Information used to verify an identity
> claimed by a SCRAM client. The authentication information for a
> SCRAM identity consists of salt, iteration count, "StoredKey" and
> "ServerKey" (as defined in the algorithm overview) **for each
> supported cryptographic hash function**.
So I'll add support for storing multiple encrypted forms for the properties
module.
--
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: 570261)
Time Spent: 10.5h (was: 10h 20m)
> Support for SASL-SCRAM
> --
>
> Key: ARTEMIS-3106
>
[jira] [Work logged] (ARTEMIS-3106) Support for SASL-SCRAM
[
https://issues.apache.org/jira/browse/ARTEMIS-3106?focusedWorklogId=570267&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570267
]
ASF GitHub Bot logged work on ARTEMIS-3106:
---
Author: ASF GitHub Bot
Created on: 23/Mar/21 06:35
Start Date: 23/Mar/21 06:35
Worklog Time Spent: 10m
Work Description: laeubi commented on a change in pull request #3470:
URL: https://github.com/apache/activemq-artemis/pull/3470#discussion_r599303571
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/scram/SCRAM.java
##
@@ -0,0 +1,62 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.spi.core.security.scram;
+
+/**
+ * Defines sets of known SCRAM types with methods to fetch matching digest and
hmac names
+ */
+public enum SCRAM {
+ SHA1,
+ SHA256,
+ SHA512;
Review comment:
Artemis includes a JMS client but I can't find how it is used, is there
an example that uses AMQP+SASL+Artemis JMS Client?
--
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: 570267)
Time Spent: 10h 40m (was: 10.5h)
> Support for SASL-SCRAM
> --
>
> Key: ARTEMIS-3106
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3106
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: AMQP
>Reporter: Christoph Läubrich
>Priority: Major
> Time Spent: 10h 40m
> Remaining Estimate: 0h
>
> With the enhancements in ARTEMIS-33 / [PR
> 3432|https://github.com/apache/activemq-artemis/pull/3432] it would be now
> possible to plug-in new SASL mechanism.
> One popular one is
> [SASL-SCRAM|https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism]
> because it allows channelbinding together with secure storage of
> user-credential.
> I have created an [implementation of this for Artemis
> AMQP|https://github.com/laeubi/scram-sasl/tree/artemis/artemis] based on the
> [SCRAM SASL authentication for Java|https://github.com/ogrebgr/scram-sasl]
> code with some enhancements/cleanups to the original.
> As the source is already Apache licensed I'd like to propose to include this
> in the Artemis code-base. This would greatly enhance the interoperability
> with other implementations e.g. Apache QPID.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
