[jira] [Work logged] (AMQ-9469) Removing JRMS dependency from assembly POM
[
https://issues.apache.org/jira/browse/AMQ-9469?focusedWorklogId=914482&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914482
]
ASF GitHub Bot logged work on AMQ-9469:
---
Author: ASF GitHub Bot
Created on: 13/Apr/24 04:43
Start Date: 13/Apr/24 04:43
Worklog Time Spent: 10m
Work Description: jbonofre commented on PR #1191:
URL: https://github.com/apache/activemq/pull/1191#issuecomment-2053464763
@kartg we ask the contributor to open the PR on `main` branch only. Then the
committer/reviewer merge and cherry-pick on branches where it makes sense.
Thanks !
Issue Time Tracking
---
Worklog Id: (was: 914482)
Time Spent: 1h 10m (was: 1h)
> Removing JRMS dependency from assembly POM
> --
>
> Key: AMQ-9469
> URL: https://issues.apache.org/jira/browse/AMQ-9469
> Project: ActiveMQ Classic
> Issue Type: Improvement
> Environment: Tested using the libraries from the ActiveMQ 5.18.3
> tarball downloaded from
> https://activemq.apache.org/components/classic/download/
>Reporter: Kartik Ganesh
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 6.2.0, 6.1.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello!
> I noticed that the ActiveMQ [assembly
> pom.xml|https://github.com/apache/activemq/blob/main/assembly/pom.xml#L484-L486]
> has a dependency on a very old library - "jrms-1.1" - and I'm wondering if
> this can be removed. This library has not seen any releases/updates since
> 2005 and [Maven|https://mvnrepository.com/artifact/jrms/jrms/usages] lists
> only ActiveMQ and Apache Camel as upstream usages.
> After digging through ActiveMQ's mailing lists and commit history, I found
> that it [used to be
> listed|https://github.com/apache/activemq-web/blob/7a7d976c/2004/06/23/jgroups-and-jrms-support.xml]
> on ActiveMQ's [URI
> Protocols|https://activemq.apache.org/components/classic/documentation/uri-protocols]
> page, but was removed at some point. JRMS seems to be listed as a
> peer-to-peer option on the
> [topologies|https://activemq.apache.org/components/classic/documentation/topologies]
> page but is not discussed in either the
> [peer|https://activemq.apache.org/components/classic/documentation/peer-transport-reference]
> or
> [multicast|https://activemq.apache.org/components/classic/documentation/multicast-transport-reference]
> transport reference pages.
> If I try to specify "jrms://" as a protocol for my ActiveMQConnectionFactory,
> I see the following stack-trace:
> {noformat}
> javax.jms.JMSException: Could not create Transport. Reason:
> java.io.IOException: Transport scheme NOT recognized: [jrms]
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:378)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:391)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:349)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:245)
> at App$HelloWorldProducer.run(App.java:66)
> at java.base/java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: Transport scheme NOT recognized: [jrms]
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:30)
> at
> org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:185)
> at
> org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:376)
> ... 5 more
> Caused by: java.io.IOException: Could not find factory class for resource:
> META-INF/services/org/apache/activemq/transport/jrms
> at
> org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.loadProperties(FactoryFinder.java:104)
> at
> org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.create(FactoryFinder.java:61)
> at
> org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:154)
> at
> org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:182)
> ... 7 more{noformat}
> An [email from 2011 on the users
> mailing-list|https://lists.apache.org/thread/wbwdj8011tmcqtdlbbfmzsthjdrh0gn0]
> came to the same conclusion, but I don't see any further discussion on it.
> I've confirmed that the
> [META-INF/services/org/apache/activemq/transport|https://github.com/apache/activemq/tree/main/activemq-client/src/main/resources/META-INF/services/org/apache/activemq/transport]
>
[jira] [Resolved] (ARTEMIS-2177) Allow to use a work-stealing thread pool executor
[ https://issues.apache.org/jira/browse/ARTEMIS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2177. - Resolution: Abandoned Obviously feel free to revisit this if you think it's worth the investment. > Allow to use a work-stealing thread pool executor > - > > Key: ARTEMIS-2177 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2177 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > Currently ActiveMQThreadPoolExecutor uses internally a shared LinkedBlocking > queue that always perform a lock to push messages into the queue and signal > to wake up any (if any) awaiting consumer thread. > This mechanics has 2 disadvantages: > - given that the Runnable queue is contended among all the offering/consuming > threads it scales negatively > - the cost on offer side of awaking a dormient thread is quite high > To improve this behaviour would be nice to use a work stealing pool that > spread the cost of using the same queue by > distributing the offers among different runnable queues and that can reduce > the cost of awaking a dormient thread only if no thread is able > to execute a submitted task. > Such work stealing pool already exists and is the ForkJoin pool available > from Java >=8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-2455) Unexpected MQTT path separator conversion handling
[
https://issues.apache.org/jira/browse/ARTEMIS-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-2455.
-
Resolution: Duplicate
[~riccardo.modan...@eurotech.com], I believe ARTEMIS-4532 has fixed this issue.
Please re-open this issue if not.
> Unexpected MQTT path separator conversion handling
> --
>
> Key: ARTEMIS-2455
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2455
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
>Affects Versions: 2.9.0
>Reporter: Riccardo Modanese
>Priority: Minor
> Attachments: MqttTopicIT.java
>
>
> Hello, I noticed an unexpected MQTT path separator conversion handling. (May
> be I'm missing some configuration parameter in the acceptor definition?)
> The char '.' on a MQTT topic is handled by Artemis as a topic separator
> instead of a "normal" topic character. So an MQTT topic like 'a.b.c.d'
> becames 'a/b/c/d'.
> I attach a Junit test I developed for testing different topics.
> I used Artemis 2.9.0. The acceptor configuration is:
> {{tcp://0.0.0.0:1883?tcpSendBufferSize=1048576&tcpReceiveBufferSize=1048576&protocols=MQTT&allowLinkStealing=true&useEpoll=true}}
>
> Regards,
> Riccardo
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4713) Mitigate NPE in LargeMessageControllerImpl
[
https://issues.apache.org/jira/browse/ARTEMIS-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4713.
-
Fix Version/s: 2.34.0
Resolution: Fixed
> Mitigate NPE in LargeMessageControllerImpl
> --
>
> Key: ARTEMIS-4713
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4713
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.34.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The semantics of the {{take}} method changed in ARTEMIS-4588 making a
> {{NullPointerException}} possible. The original semantics should be restored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4714) Mitigate NPE in FederatedQueueConsumerImpl MessageListener
[ https://issues.apache.org/jira/browse/ARTEMIS-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4714. - Fix Version/s: 2.34.0 Resolution: Fixed > Mitigate NPE in FederatedQueueConsumerImpl MessageListener > -- > > Key: ARTEMIS-4714 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4714 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.34.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4704) Eliminate unnecessary variable in ReplicationManager
[ https://issues.apache.org/jira/browse/ARTEMIS-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4704. - Fix Version/s: 2.34.0 Resolution: Fixed > Eliminate unnecessary variable in ReplicationManager > > > Key: ARTEMIS-4704 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4704 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4698) MetricsManagers' remove method may cause a NullPointerException
[
https://issues.apache.org/jira/browse/ARTEMIS-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4698.
-
Fix Version/s: 2.34.0
Resolution: Fixed
> MetricsManagers' remove method may cause a NullPointerException
>
>
> Key: ARTEMIS-4698
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4698
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.27.0, 2.27.1, 2.28.0, 2.29.0, 2.30.0, 2.31.0, 2.31.1,
> 2.31.2, 2.32.0, 2.33.0
>Reporter: Jelle Smits
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.34.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I recently switched from Artemis-server 2.19.1 to 2.31.1. From this point, I
> have been experiencing a lot the following errors:
> {noformat}
> AMQ224065: Failed to remove auto-created queue xyz{noformat}
> The stack trace shows that this consistenly happens in the {{remove}} call of
> the {{MetricsManager}}. More specifically, the {{logger.debug}} statement
> which uses the {{removed}} variable:
> {noformat}
> java.lang.NullPointerException: Cannot invoke
> "io.micrometer.core.instrument.Meter.getId()" because "removed" is null
> at
> org.apache.activemq.artemis.core.server.metrics.MetricsManager.remove(MetricsManager.java:167){noformat}
> This did not happen in the previous version, as prior to ARTEMIS-4020 the log
> statement was conditional based on whether debug logging was enabled.
> While the issue at hand may be caused by my application (un)registering
> additional metrics on some queues, I feel the {{MeterRegistry}} should
> include a null-check for the value of removed, as by the JavaDoc of
> Micrometers' MeterRegistry, the meterRegistry.remove will return:
> bq. The removed meter, or null if the provided meter is not currently
> registered.
> Also, as a {{null}} from the {{MeterRegistry}} means that the metric no
> longer exists, as this is a remove call that should not be a blocking issue.
> I currently work around the issue using a class overload with an inline null
> check:
> {code:java}
> logger.debug("Unregistered meter: {}", removed != null ? removed.getId() :
> "null");{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4712) Remove LDAP connection pooling
[
https://issues.apache.org/jira/browse/ARTEMIS-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4712.
-
Fix Version/s: 2.34.0
Resolution: Fixed
> Remove LDAP connection pooling
> --
>
> Key: ARTEMIS-4712
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4712
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.34.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{LDAPLoginModule}} supports connection pooling, but there have been
> reports of weird behavior with pooling vs. without. For example, with pooling
> once a login failure occurs subsequent login attempts also fail - even if
> credentials are valid. However, without pooling this behavior is never seen.
> Upon further investigation the [Oracle
> documentation|https://docs.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html]
> says this:
> bq. Pooled connections are intended to be reused. Therefore, if you plan to
> perform operations on a Context instance that might alter the underlying
> connection's state, then you should not use connection pooling for that
> Context instance. For example, if you plan to invoke the Start TLS extended
> operation on a Context instance, or plan to change security-related
> properties (such as "java.naming.security.principal" or
> "java.naming.security.protocol") after the initial context has been created,
> you should not use connection pooling for that Context instance because the
> LDAP provider does not track any such state changes. If you use connection
> pooling in such situations, you might be compromising the security of your
> application.
> The {{LDAPLoginModule}} does, in fact, modify the
> {{java.naming.security.principal}} of the {{Context}} (i.e. in the
> {{bindUser}} method). Although the {{Context}} is immediately reset to the
> original values (ostensibly restoring normal pool behavior) the pooling
> functionality should be removed in an abundance of caution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4702) Only run command needs custom JVM settings
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?focusedWorklogId=914479&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914479
]
ASF GitHub Bot logged work on ARTEMIS-4702:
---
Author: ASF GitHub Bot
Created on: 12/Apr/24 21:42
Start Date: 12/Apr/24 21:42
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #4885:
URL: https://github.com/apache/activemq-artemis/pull/4885
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 914479)
Remaining Estimate: 0h
Time Spent: 10m
> Only run command needs custom JVM settings
> --
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{artemis.profile}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{queue stat}}, {{consumer}}, {{producer}},
> etc. commands as well. At best, it's overkill to use 8G of memory for these
> secondary commands and at worst it can actually prevent them from operating
> at all (e.g. if the machine is low on memory).
> JVM settings really only need to apply to the {{run}} command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4648) Support typed properties on CLI producer
[
https://issues.apache.org/jira/browse/ARTEMIS-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram closed ARTEMIS-4648.
---
Resolution: Fixed
> Support typed properties on CLI producer
>
>
> Key: ARTEMIS-4648
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4648
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> It would be useful if the {{producer}} CLI command supported headers. This
> could be done via simple JSON to specify a list of keys, values, and types,
> e.g.:
> {noformat}
> [{"key":"key1","value":"value1","type":"type1"},{"key2","value2","type2"}]{noformat}
> Supported types:
> - {{boolean}}
> - {{byte}}
> - {{short}}
> - {{int}}
> - {{long}}
> - {{float}}
> - {{double}}
> - {{string}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4407) Add support for headers in CLI producer
[
https://issues.apache.org/jira/browse/ARTEMIS-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4407.
-
Resolution: Duplicate
> Add support for headers in CLI producer
> ---
>
> Key: ARTEMIS-4407
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4407
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> It would be useful if the {{producer}} CLI command supported headers. This
> could be done via simple JSON to specify a list of keys, values, and types,
> e.g.:
> {noformat}
> [{"key":"key1","value":"value1","type":"type1"},{"key2","value2","type2"}]{noformat}
> Supported types:
> - {{boolean}}
> - {{byte}}
> - {{short}}
> - {{int}}
> - {{long}}
> - {{float}}
> - {{double}}
> - {{string}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4648) Support typed properties on CLI producer
[
https://issues.apache.org/jira/browse/ARTEMIS-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4648:
Description:
It would be useful if the {{producer}} CLI command supported headers. This
could be done via simple JSON to specify a list of keys, values, and types,
e.g.:
{noformat}
[{"key":"key1","value":"value1","type":"type1"},{"key2","value2","type2"}]{noformat}
Supported types:
- {{boolean}}
- {{byte}}
- {{short}}
- {{int}}
- {{long}}
- {{float}}
- {{double}}
- {{string}}
> Support typed properties on CLI producer
>
>
> Key: ARTEMIS-4648
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4648
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> It would be useful if the {{producer}} CLI command supported headers. This
> could be done via simple JSON to specify a list of keys, values, and types,
> e.g.:
> {noformat}
> [{"key":"key1","value":"value1","type":"type1"},{"key2","value2","type2"}]{noformat}
> Supported types:
> - {{boolean}}
> - {{byte}}
> - {{short}}
> - {{int}}
> - {{long}}
> - {{float}}
> - {{double}}
> - {{string}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4648) Support typed properties on CLI producer
[ https://issues.apache.org/jira/browse/ARTEMIS-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reopened ARTEMIS-4648: - > Support typed properties on CLI producer > > > Key: ARTEMIS-4648 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4648 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.33.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4625) Upgrade CheckStyle to 10.15.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4625?focusedWorklogId=914478&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914478 ] ASF GitHub Bot logged work on ARTEMIS-4625: --- Author: ASF GitHub Bot Created on: 12/Apr/24 21:34 Start Date: 12/Apr/24 21:34 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4884: URL: https://github.com/apache/activemq-artemis/pull/4884 (no comment) Issue Time Tracking --- Worklog Id: (was: 914478) Remaining Estimate: 0h Time Spent: 10m > Upgrade CheckStyle to 10.15.0 > - > > Key: ARTEMIS-4625 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4625 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4625) Upgrade CheckStyle to 10.15.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4625: Summary: Upgrade CheckStyle to 10.15.0 (was: Upgrade CheckStyle to 10.13.0) > Upgrade CheckStyle to 10.15.0 > - > > Key: ARTEMIS-4625 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4625 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3259) broker-connection mirror does not strip anycastPrefix
[
https://issues.apache.org/jira/browse/ARTEMIS-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836746#comment-17836746
]
Justin Bertram commented on ARTEMIS-3259:
-
This looks like a legitimate issue. Do you have any thoughts on this,
[~clebertsuconic]?
> broker-connection mirror does not strip anycastPrefix
> -
>
> Key: ARTEMIS-3259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.17.0
> Environment: artemis 2.17.0
> I have seen this both in docker on macOS, and running on a linux server
> (without docker).
>Reporter: Stephen Baker
>Priority: Major
>
> Setup two instances that use broker-connection mirroring to replicate from
> one to the other.
> On both instances add the anycastPrefix as documented in the acceptors note
> e.g.:
> {code:xml}
> name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;anycastPrefix=jms.queue.;multicastPrefix=jms.topic.{code}
> Then add a {{broker-connection}} on the primary instance e.g.:
> {code:xml}
>
> name="DRMirror1M" user="artemis" password="artemis" auto-start="true">
>
>
> {code}
> Then send a couple messages to a queue on the primary instance, some using
> the prefixed address some without.
> Observe that all of the messages are on the queue on the primary instance,
> but on the mirror only the messages without the prefix are on the queue. If
> you setup a second queue on the mirror with an address that includes the
> prefix those messages get delivered to it instead.
> No messages appear in the log to indicate a problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-1729) Automatically check for broken documentation links
[
https://issues.apache.org/jira/browse/ARTEMIS-1729?focusedWorklogId=914475&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914475
]
ASF GitHub Bot logged work on ARTEMIS-1729:
---
Author: ASF GitHub Bot
Created on: 12/Apr/24 21:06
Start Date: 12/Apr/24 21:06
Worklog Time Spent: 10m
Work Description: jbertram merged PR #4882:
URL: https://github.com/apache/activemq-artemis/pull/4882
Issue Time Tracking
---
Worklog Id: (was: 914475)
Time Spent: 20m (was: 10m)
> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Documentation
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Artemis GitBook documentation sometimes contains broken (internal) links.
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving
> the generated documentation (Python can trivially do it with '{{python -m
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably
> better) and then a crawler checking for broken links ({{wget}} can easily be
> used for this as described in ARTEMIS-1076 but here again a Java-based
> solution is maybe better).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-1729) Automatically check for broken documentation links
[
https://issues.apache.org/jira/browse/ARTEMIS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1729.
-
Resolution: Fixed
> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Documentation
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Artemis GitBook documentation sometimes contains broken (internal) links.
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving
> the generated documentation (Python can trivially do it with '{{python -m
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably
> better) and then a crawler checking for broken links ({{wget}} can easily be
> used for this as described in ARTEMIS-1076 but here again a Java-based
> solution is maybe better).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1729) Automatically check for broken documentation links
[
https://issues.apache.org/jira/browse/ARTEMIS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836745#comment-17836745
]
ASF subversion and git services commented on ARTEMIS-1729:
--
Commit 66fcd7f4cf554a833d0fe3ee7760d2e083e01fca in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=66fcd7f4cf ]
ARTEMIS-1729 automatically check for broken documentation links
> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Documentation
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Artemis GitBook documentation sometimes contains broken (internal) links.
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving
> the generated documentation (Python can trivially do it with '{{python -m
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably
> better) and then a crawler checking for broken links ({{wget}} can easily be
> used for this as described in ARTEMIS-1076 but here again a Java-based
> solution is maybe better).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-1070) provide some transaction manager locator OOTB
[
https://issues.apache.org/jira/browse/ARTEMIS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1070.
-
Resolution: Won't Do
If more folks ask for this we might devote some development cycles to it.
> provide some transaction manager locator OOTB
> -
>
> Key: ARTEMIS-1070
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1070
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> If you want to use a tx mgr with artemis you need to write a locator for it.
> Would be great to support it OOTB for well known server.
> For openejb it looks like
> {code}
> import
> org.apache.activemq.artemis.service.extensions.transactions.TransactionManagerLocator;
> import org.apache.openejb.OpenEJB;
> import javax.transaction.TransactionManager;
> public class OpenEJBTransactionManagerLocator implements
> TransactionManagerLocator {
> @Override
> public TransactionManager getTransactionManager() {
> return OpenEJB.getTransactionManager();
> }
> }
> {code}
> But it is also accessible through JNDI which would fit ost of servers.
> OpenJPA has a good class to lookup the transaction manager (see
> https://github.com/apache/openjpa/blob/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java#L55)
> maybe it can be used as a starting point to get impl automatic and just a
> flag to activate the tx mgr usage or not.
> wdyt?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-1040) MQTT: Investigate handling of duplicate messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1040. - Resolution: Fixed [~orpiske], can you provide a clear way to reproduce this? > MQTT: Investigate handling of duplicate messages > > > Key: ARTEMIS-1040 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1040 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Otavio Rodolfo Piske >Priority: Major > Attachments: artemis-test.txt, mosquito-test.txt > > > When running the Eclipse's Paho MQTT C tests on top of the broker, one of the > tests fail because all the messages received seem to have the duplicate flag. > The test flow is similar to this: > 1. Connect to the broker with QoS 1 and clean session 1. > 2. Sends a batch of 3 messages and disconnect right after that. > 3. Perform internal verification of pending deliveries and cleanup (possibly > non important for the test). > 4. Connect again using the same connection options as before. At this point, > the client seems to automatically resend the messages (possibly due to the > lack of the PUBACK). > 5. Tries to receive the 3 messages sent. At this point, the behavior between > Artemis and Mosquitto differ: Mosquitto replies back with 6 messages (of > those 3 are marked as duplicate and 3 are not marked). Artemis replies back > with 6 messages and all of them are marked as duplicate. > I am not entirely sure if this is a bug or not, but I am opening a ticket > based on my discussion with the developers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-1691) JMS Bridge: After the FailureHandler exits, a bridge cannot be started full functional anymore
[
https://issues.apache.org/jira/browse/ARTEMIS-1691?focusedWorklogId=914472&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914472
]
ASF GitHub Bot logged work on ARTEMIS-1691:
---
Author: ASF GitHub Bot
Created on: 12/Apr/24 20:36
Start Date: 12/Apr/24 20:36
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #4883:
URL: https://github.com/apache/activemq-artemis/pull/4883
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 914472)
Remaining Estimate: 0h
Time Spent: 10m
> JMS Bridge: After the FailureHandler exits, a bridge cannot be started full
> functional anymore
> --
>
> Key: ARTEMIS-1691
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1691
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: WildFly Servers.
>Reporter: Markus F
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h4. Setup
> JMSBridge on server a pulls messages from a remote server B.
> failureRetryInterval = 1 sec
> maxRetries = 1
> h4. To Reproduce
> Restart the remote server (need to take more than one second.)
> JMS Bridge prints out:
> {noformat}
> JMS Bridge unable to set up connections, bridge will be stopped{noformat}
> After the remote server is up again, start the bridge again.
> JMS Bridge prints out:
> {noformat}
> Started JMS Bridge testbridge{noformat}
> h4. Result:
> The bridge is started, but does still not consume messages.
> h4. Reason
> In {{JMSBridgeImpl}} line 1624, the failed boolean parameter is checked. It
> is not set to true anywhere outside the failure handlers ({{FailureHandler}}
> and {{StartupFailureHandler}}) or on initial adding of the bridge.
> But the {{FailureHandler}} has already exited. So the bridge will wait all
> time long for 500 ms in line 1626.
> h4. Solution
> I would add a
> {code:java}
> failed = false;{code}
> after line 403.
> I don't know how the release process is handled here, if I can make a pull
> request or something like that, I will do, if it is needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-1691) JMS Bridge: After the FailureHandler exits, a bridge cannot be started full functional anymore
[
https://issues.apache.org/jira/browse/ARTEMIS-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-1691:
---
Assignee: Justin Bertram
> JMS Bridge: After the FailureHandler exits, a bridge cannot be started full
> functional anymore
> --
>
> Key: ARTEMIS-1691
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1691
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: WildFly Servers.
>Reporter: Markus F
>Assignee: Justin Bertram
>Priority: Minor
>
> h4. Setup
> JMSBridge on server a pulls messages from a remote server B.
> failureRetryInterval = 1 sec
> maxRetries = 1
> h4. To Reproduce
> Restart the remote server (need to take more than one second.)
> JMS Bridge prints out:
> {noformat}
> JMS Bridge unable to set up connections, bridge will be stopped{noformat}
> After the remote server is up again, start the bridge again.
> JMS Bridge prints out:
> {noformat}
> Started JMS Bridge testbridge{noformat}
> h4. Result:
> The bridge is started, but does still not consume messages.
> h4. Reason
> In {{JMSBridgeImpl}} line 1624, the failed boolean parameter is checked. It
> is not set to true anywhere outside the failure handlers ({{FailureHandler}}
> and {{StartupFailureHandler}}) or on initial adding of the bridge.
> But the {{FailureHandler}} has already exited. So the bridge will wait all
> time long for 500 ms in line 1626.
> h4. Solution
> I would add a
> {code:java}
> failed = false;{code}
> after line 403.
> I don't know how the release process is handled here, if I can make a pull
> request or something like that, I will do, if it is needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (AMQ-9480) Update activemq-osgi import for Jetty 11
Matt Pavlovich created AMQ-9480: --- Summary: Update activemq-osgi import for Jetty 11 Key: AMQ-9480 URL: https://issues.apache.org/jira/browse/AMQ-9480 Project: ActiveMQ Classic Issue Type: Task Reporter: Matt Pavlovich -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9480) Update activemq-osgi import for Jetty 11
[ https://issues.apache.org/jira/browse/AMQ-9480?focusedWorklogId=914454&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914454 ] ASF GitHub Bot logged work on AMQ-9480: --- Author: ASF GitHub Bot Created on: 12/Apr/24 18:30 Start Date: 12/Apr/24 18:30 Worklog Time Spent: 10m Work Description: mattrpav opened a new pull request, #1205: URL: https://github.com/apache/activemq/pull/1205 (no comment) Issue Time Tracking --- Worklog Id: (was: 914454) Remaining Estimate: 0h Time Spent: 10m > Update activemq-osgi import for Jetty 11 > > > Key: AMQ-9480 > URL: https://issues.apache.org/jira/browse/AMQ-9480 > Project: ActiveMQ Classic > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AMQ-9480) Update activemq-osgi import for Jetty 11
[ https://issues.apache.org/jira/browse/AMQ-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich reassigned AMQ-9480: --- Assignee: Matt Pavlovich > Update activemq-osgi import for Jetty 11 > > > Key: AMQ-9480 > URL: https://issues.apache.org/jira/browse/AMQ-9480 > Project: ActiveMQ Classic > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 6.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9480) Update activemq-osgi import for Jetty 11
[ https://issues.apache.org/jira/browse/AMQ-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-9480: Fix Version/s: 6.2.0 > Update activemq-osgi import for Jetty 11 > > > Key: AMQ-9480 > URL: https://issues.apache.org/jira/browse/AMQ-9480 > Project: ActiveMQ Classic > Issue Type: Task >Reporter: Matt Pavlovich >Priority: Minor > Fix For: 6.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-1691) JMS Bridge: After the FailureHandler exits, a bridge cannot be started full functional anymore
[
https://issues.apache.org/jira/browse/ARTEMIS-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1691:
Description:
h4. Setup
JMSBridge on server a pulls messages from a remote server B.
failureRetryInterval = 1 sec
maxRetries = 1
h4. To Reproduce
Restart the remote server (need to take more than one second.)
JMS Bridge prints out:
{noformat}
JMS Bridge unable to set up connections, bridge will be stopped{noformat}
After the remote server is up again, start the bridge again.
JMS Bridge prints out:
{noformat}
Started JMS Bridge testbridge{noformat}
h4. Result:
The bridge is started, but does still not consume messages.
h4. Reason
In {{JMSBridgeImpl}} line 1624, the failed boolean parameter is checked. It is
not set to true anywhere outside the failure handlers ({{FailureHandler}} and
{{StartupFailureHandler}}) or on initial adding of the bridge.
But the {{FailureHandler}} has already exited. So the bridge will wait all time
long for 500 ms in line 1626.
h4. Solution
I would add a
{code:java}
failed = false;{code}
after line 403.
I don't know how the release process is handled here, if I can make a pull
request or something like that, I will do, if it is needed.
was:
h4. Setup:
JMSBridge on server a pulls messages from a remote server b.
failureRetryInterval = 1 sec
maxRetries = 1
h4. To reproduce:
Restart the remote server (need to take more than one second.)
JMS Bridge prints out:
{noformat}
JMS Bridge unable to set up connections, bridge will be stopped{noformat}
After the remote server is up again, start the bridge again.
JMS Bridge prints out:
{noformat}
Started JMS Bridge testbridge{noformat}
h4. Result:
The bridge ist started, but does still not consume messages
h4. Reason:
In the Class JMSBridgeImpl line 1624, the failed boolean parameter is checked.
It is not set to true anywhere outside the failure handlers (FailureHandler and
StartupFailureHandler) or on initial adding of the bridge.
But the FailureHandler has already exited. So the bridge will wait all time
long for 500 ms in line 1626.
h4. Solution:
I would add a
{code:java}
failed = false;{code}
after line 403.
I don't know how the release process is handled here, if I can make a pull
request or something like that, I will do, if it is needed.
Cheers,
Markus
> JMS Bridge: After the FailureHandler exits, a bridge cannot be started full
> functional anymore
> --
>
> Key: ARTEMIS-1691
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1691
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: WildFly Servers.
>Reporter: Markus F
>Priority: Minor
>
> h4. Setup
> JMSBridge on server a pulls messages from a remote server B.
> failureRetryInterval = 1 sec
> maxRetries = 1
> h4. To Reproduce
> Restart the remote server (need to take more than one second.)
> JMS Bridge prints out:
> {noformat}
> JMS Bridge unable to set up connections, bridge will be stopped{noformat}
> After the remote server is up again, start the bridge again.
> JMS Bridge prints out:
> {noformat}
> Started JMS Bridge testbridge{noformat}
> h4. Result:
> The bridge is started, but does still not consume messages.
> h4. Reason
> In {{JMSBridgeImpl}} line 1624, the failed boolean parameter is checked. It
> is not set to true anywhere outside the failure handlers ({{FailureHandler}}
> and {{StartupFailureHandler}}) or on initial adding of the bridge.
> But the {{FailureHandler}} has already exited. So the bridge will wait all
> time long for 500 ms in line 1626.
> h4. Solution
> I would add a
> {code:java}
> failed = false;{code}
> after line 403.
> I don't know how the release process is handled here, if I can make a pull
> request or something like that, I will do, if it is needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1827) Improve HA tests to use remote brokers and not invm
[ https://issues.apache.org/jira/browse/ARTEMIS-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836710#comment-17836710 ] Justin Bertram commented on ARTEMIS-1827: - [~andytaylor], is this still worth doing? > Improve HA tests to use remote brokers and not invm > --- > > Key: ARTEMIS-1827 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1827 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > > This could possibly be implemented using Arquillian which allows resource > life cycle control -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-1807) File-based Large Message encoding should use read-only mmap
[ https://issues.apache.org/jira/browse/ARTEMIS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1807. - Resolution: Abandoned Feel free to re-open this if you pick this back up. > File-based Large Message encoding should use read-only mmap > --- > > Key: ARTEMIS-1807 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1807 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.5.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > File-based LargeServerMessageImpl should use read-only memory mapping while > reading the file, in order to: > * reduce the number of copies > * reduce the context switches -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-3259) broker-connection mirror does not strip anycastPrefix
[
https://issues.apache.org/jira/browse/ARTEMIS-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-3259:
Description:
Setup two instances that use broker-connection mirroring to replicate from one
to the other.
On both instances add the anycastPrefix as documented in the acceptors note
e.g.:
{code:xml}
tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;anycastPrefix=jms.queue.;multicastPrefix=jms.topic.{code}
Then add a {{broker-connection}} on the primary instance e.g.:
{code:xml}
{code}
Then send a couple messages to a queue on the primary instance, some using the
prefixed address some without.
Observe that all of the messages are on the queue on the primary instance, but
on the mirror only the messages without the prefix are on the queue. If you
setup a second queue on the mirror with an address that includes the prefix
those messages get delivered to it instead.
No messages appear in the log to indicate a problem.
was:
Setup two instances that use broker-connection mirroring to replicate from one
to the other.
On both instances add the anycastPrefix as documented in the acceptors note
e.g.:
{{tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;anycastPrefix=jms.queue.;multicastPrefix=jms.topic.}}
and add a broker-connection on the primary instance e.g.:
{{ }}
{{ }}
{{ }}
Then send a couple messages to a queue on the primary instance, some using the
prefixed address some without.
Observe that all of the messages are on the queue on the primary instance, but
on the mirror only the messages without the prefix are on the queue. If you
setup a second queue on the mirror with an address that includes the prefix
those messages get delivered to it instead.
No messages appear in the log to indicate a problem.
> broker-connection mirror does not strip anycastPrefix
> -
>
> Key: ARTEMIS-3259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.17.0
> Environment: artemis 2.17.0
> I have seen this both in docker on macOS, and running on a linux server
> (without docker).
>Reporter: Stephen Baker
>Priority: Major
>
> Setup two instances that use broker-connection mirroring to replicate from
> one to the other.
> On both instances add the anycastPrefix as documented in the acceptors note
> e.g.:
> {code:xml}
> name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;anycastPrefix=jms.queue.;multicastPrefix=jms.topic.{code}
> Then add a {{broker-connection}} on the primary instance e.g.:
> {code:xml}
>
> name="DRMirror1M" user="artemis" password="artemis" auto-start="true">
>
>
> {code}
> Then send a couple messages to a queue on the primary instance, some using
> the prefixed address some without.
> Observe that all of the messages are on the queue on the primary instance,
> but on the mirror only the messages without the prefix are on the queue. If
> you setup a second queue on the mirror with an address that includes the
> prefix those messages get delivered to it instead.
> No messages appear in the log to indicate a problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQ-9469) Removing JRMS dependency from assembly POM
[
https://issues.apache.org/jira/browse/AMQ-9469?focusedWorklogId=914443&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914443
]
ASF GitHub Bot logged work on AMQ-9469:
---
Author: ASF GitHub Bot
Created on: 12/Apr/24 17:06
Start Date: 12/Apr/24 17:06
Worklog Time Spent: 10m
Work Description: kartg commented on PR #1191:
URL: https://github.com/apache/activemq/pull/1191#issuecomment-2052145965
Thank you! In future, would you prefer that requestors submit the backport
PR so you don't have to manage it?
Possibly useful - there's a [backport GH
action](https://github.com/marketplace/actions/backporting) which I've used on
other projects that can automate backports based on labels.
Issue Time Tracking
---
Worklog Id: (was: 914443)
Time Spent: 1h (was: 50m)
> Removing JRMS dependency from assembly POM
> --
>
> Key: AMQ-9469
> URL: https://issues.apache.org/jira/browse/AMQ-9469
> Project: ActiveMQ Classic
> Issue Type: Improvement
> Environment: Tested using the libraries from the ActiveMQ 5.18.3
> tarball downloaded from
> https://activemq.apache.org/components/classic/download/
>Reporter: Kartik Ganesh
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 6.2.0, 6.1.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Hello!
> I noticed that the ActiveMQ [assembly
> pom.xml|https://github.com/apache/activemq/blob/main/assembly/pom.xml#L484-L486]
> has a dependency on a very old library - "jrms-1.1" - and I'm wondering if
> this can be removed. This library has not seen any releases/updates since
> 2005 and [Maven|https://mvnrepository.com/artifact/jrms/jrms/usages] lists
> only ActiveMQ and Apache Camel as upstream usages.
> After digging through ActiveMQ's mailing lists and commit history, I found
> that it [used to be
> listed|https://github.com/apache/activemq-web/blob/7a7d976c/2004/06/23/jgroups-and-jrms-support.xml]
> on ActiveMQ's [URI
> Protocols|https://activemq.apache.org/components/classic/documentation/uri-protocols]
> page, but was removed at some point. JRMS seems to be listed as a
> peer-to-peer option on the
> [topologies|https://activemq.apache.org/components/classic/documentation/topologies]
> page but is not discussed in either the
> [peer|https://activemq.apache.org/components/classic/documentation/peer-transport-reference]
> or
> [multicast|https://activemq.apache.org/components/classic/documentation/multicast-transport-reference]
> transport reference pages.
> If I try to specify "jrms://" as a protocol for my ActiveMQConnectionFactory,
> I see the following stack-trace:
> {noformat}
> javax.jms.JMSException: Could not create Transport. Reason:
> java.io.IOException: Transport scheme NOT recognized: [jrms]
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:378)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:391)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:349)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:245)
> at App$HelloWorldProducer.run(App.java:66)
> at java.base/java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: Transport scheme NOT recognized: [jrms]
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:30)
> at
> org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:185)
> at
> org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:376)
> ... 5 more
> Caused by: java.io.IOException: Could not find factory class for resource:
> META-INF/services/org/apache/activemq/transport/jrms
> at
> org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.loadProperties(FactoryFinder.java:104)
> at
> org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.create(FactoryFinder.java:61)
> at
> org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:154)
> at
> org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:182)
> ... 7 more{noformat}
> An [email from 2011 on the users
> mailing-list|https://lists.apache.org/thread/wbwdj8011tmcqtdlbbfmzsthjdrh0gn0]
> came to the same conclusion, but I don't see any further discussion on it.
> I've confirmed that the
> [META-INF/services/org/apache/activemq/transport|http
[jira] [Commented] (ARTEMIS-1551) Conversion of most of the properties is not working when crossing protocols.
[
https://issues.apache.org/jira/browse/ARTEMIS-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836696#comment-17836696
]
ASF subversion and git services commented on ARTEMIS-1551:
--
Commit f64e37622e3216be77d409b6327990f8fe4a7b00 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f64e37622e ]
ARTEMIS-1551 validate properties between JMS clients
> Conversion of most of the properties is not working when crossing protocols.
>
>
> Key: ARTEMIS-1551
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1551
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, OpenWire
>Affects Versions: 2.3.0, 2.4.0
> Environment: Artemis 2.3.0
>Reporter: Saurabh Rai
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Send a message using Openwire client
> Receive a message using AMQP client.
> Observe most of the fields like 'group-id', 'group-sequence',
> 'reply-to-group-id' are not getting converted properly.
> {code:java}
> $ java -jar aoc-downstream-ga-5.11.0.redhat-630187.jar sender --timeout 5000
> --log-msgs dict --broker tcp://localhost:61616 --address saurabhTest --count
> 1 --conn-username admin --conn-password admin --msg-user-id tester
> --msg-group-id g1 --msg-group-seq 10 --msg-content-type application/text
> --msg-reply-to-group-id g1
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False,
> 'delivery-count': 0, 'redelivered': False, 'id':
> 'ID:sarai.pnq.csb-44142-1512964029323-1:1:1:1:1', 'user_id':'tester',
> 'address': 'queue://saurabhTest', 'subject': None, 'reply_to': None,
> 'correlation_id': None, 'content_type': 'application/text',
> 'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time':
> 1512964029569, 'group-id': 'g1', 'group-sequence': 10, 'reply-to-group-id':
> 'g1', 'properties': {'JMS_AMQP_ContentType': 'application/text',
> 'JMS_AMQP_ReplyToGroupID': 'g1', 'JMSXUserID': 'tester', 'JMSXGroupSequence':
> '10', 'JMSXGroupID': 'g1', 'JMSXGroupSeq': 0}, 'content': None, 'type': None}
> {code}
> {code:java}
> $ java -jar aac-staging-0.21.0.redhat-1.jar receiver --timeout 5 --log-msgs
> dict --broker localhost:5672 --address saurabhTest --count 1 --conn-username
> admin --conn-password admin
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x00\x01\x00\x0aJMSXUserID\x09\x00\x06tester
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x005n\x02\xae\x02{\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01\x00\x01
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x001{\x01+\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False,
> 'delivery-count': 0, 'redelivered': False, 'id': None, 'user_id': 'tester',
> 'address': 'saurabhTest', 'subject': None, 'reply_to': None,
> 'correlation_id': None, 'content_type': None, 'content_encoding': None,
> 'absolute-expiry-time': 0, 'creation-time': 1512712172006, 'group-id': None,
> 'group-sequence': 0, 'reply-to-group-id': None, 'properties':
> {'__HDR_COMMAND_ID': 5, 'JMSXDeliveryCount': 1, '__HDR_ARRIVAL': 0,
> '__HDR_GROUP_ID': 'g1', 'JMSXUserID': 'tester', '__HDR_MARSHALL_PROP':
> \x00\x00\x00\x01\x00\x0aJMSXUserID\x09\x00\x06tester, '__HDR_MESSAGE_ID':
> \x00\x00\x005n\x02\xae\x02{\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01\x00\x01,
> '__HDR_GROUP_SEQUENCE': 0, '__HDR_PRODUCER_ID':
> \x00\x00\x001{\x01+\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01,
> '__HDR_DROPPABLE': False, '__HDR_BROKER_IN_TIME': 1512712172007}, 'content':
> None}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-1551) Conversion of most of the properties is not working when crossing protocols.
[
https://issues.apache.org/jira/browse/ARTEMIS-1551?focusedWorklogId=914441&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914441
]
ASF GitHub Bot logged work on ARTEMIS-1551:
---
Author: ASF GitHub Bot
Created on: 12/Apr/24 17:03
Start Date: 12/Apr/24 17:03
Worklog Time Spent: 10m
Work Description: jbertram merged PR #4881:
URL: https://github.com/apache/activemq-artemis/pull/4881
Issue Time Tracking
---
Worklog Id: (was: 914441)
Time Spent: 20m (was: 10m)
> Conversion of most of the properties is not working when crossing protocols.
>
>
> Key: ARTEMIS-1551
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1551
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, OpenWire
>Affects Versions: 2.3.0, 2.4.0
> Environment: Artemis 2.3.0
>Reporter: Saurabh Rai
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Send a message using Openwire client
> Receive a message using AMQP client.
> Observe most of the fields like 'group-id', 'group-sequence',
> 'reply-to-group-id' are not getting converted properly.
> {code:java}
> $ java -jar aoc-downstream-ga-5.11.0.redhat-630187.jar sender --timeout 5000
> --log-msgs dict --broker tcp://localhost:61616 --address saurabhTest --count
> 1 --conn-username admin --conn-password admin --msg-user-id tester
> --msg-group-id g1 --msg-group-seq 10 --msg-content-type application/text
> --msg-reply-to-group-id g1
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False,
> 'delivery-count': 0, 'redelivered': False, 'id':
> 'ID:sarai.pnq.csb-44142-1512964029323-1:1:1:1:1', 'user_id':'tester',
> 'address': 'queue://saurabhTest', 'subject': None, 'reply_to': None,
> 'correlation_id': None, 'content_type': 'application/text',
> 'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time':
> 1512964029569, 'group-id': 'g1', 'group-sequence': 10, 'reply-to-group-id':
> 'g1', 'properties': {'JMS_AMQP_ContentType': 'application/text',
> 'JMS_AMQP_ReplyToGroupID': 'g1', 'JMSXUserID': 'tester', 'JMSXGroupSequence':
> '10', 'JMSXGroupID': 'g1', 'JMSXGroupSeq': 0}, 'content': None, 'type': None}
> {code}
> {code:java}
> $ java -jar aac-staging-0.21.0.redhat-1.jar receiver --timeout 5 --log-msgs
> dict --broker localhost:5672 --address saurabhTest --count 1 --conn-username
> admin --conn-password admin
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x00\x01\x00\x0aJMSXUserID\x09\x00\x06tester
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x005n\x02\xae\x02{\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01\x00\x01
> Unsupported object type org.apache.qpid.proton.amqp.Binary
> \x00\x00\x001{\x01+\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01
> {'durable': True, 'priority': 4, 'ttl': 0, 'first-acquirer': False,
> 'delivery-count': 0, 'redelivered': False, 'id': None, 'user_id': 'tester',
> 'address': 'saurabhTest', 'subject': None, 'reply_to': None,
> 'correlation_id': None, 'content_type': None, 'content_encoding': None,
> 'absolute-expiry-time': 0, 'creation-time': 1512712172006, 'group-id': None,
> 'group-sequence': 0, 'reply-to-group-id': None, 'properties':
> {'__HDR_COMMAND_ID': 5, 'JMSXDeliveryCount': 1, '__HDR_ARRIVAL': 0,
> '__HDR_GROUP_ID': 'g1', 'JMSXUserID': 'tester', '__HDR_MARSHALL_PROP':
> \x00\x00\x00\x01\x00\x0aJMSXUserID\x09\x00\x06tester, '__HDR_MESSAGE_ID':
> \x00\x00\x005n\x02\xae\x02{\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01\x00\x01,
> '__HDR_GROUP_SEQUENCE': 0, '__HDR_PRODUCER_ID':
> \x00\x00\x001{\x01+\x00(ID:sarai.pnq.csb-33773-1512712171740-1:1\x00\x01\x00\x01,
> '__HDR_DROPPABLE': False, '__HDR_BROKER_IN_TIME': 1512712172007}, 'content':
> None}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-1027) Use AMQP.MessageID as the duplicateID
[ https://issues.apache.org/jira/browse/ARTEMIS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1027. - Resolution: Abandoned > Use AMQP.MessageID as the duplicateID > - > > Key: ARTEMIS-1027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1027 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP >Affects Versions: 2.0.0 >Reporter: Clebert Suconic >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4694) Servers should be resilient to large headers
[ https://issues.apache.org/jira/browse/ARTEMIS-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4694. - Resolution: Fixed > Servers should be resilient to large headers > > > Key: ARTEMIS-4694 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4694 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Users should not use large headers, but in case they did the server should > not be stopped or become unstable. Producers may get exceptions but the > server should still behave fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4694) Servers should be resilient to large headers
[ https://issues.apache.org/jira/browse/ARTEMIS-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-4694: --- Assignee: Clebert Suconic > Servers should be resilient to large headers > > > Key: ARTEMIS-4694 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4694 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Users should not use large headers, but in case they did the server should > not be stopped or become unstable. Producers may get exceptions but the > server should still behave fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-1729) Automatically check for broken documentation links
[
https://issues.apache.org/jira/browse/ARTEMIS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-1729:
---
Assignee: Justin Bertram
> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Documentation
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Artemis GitBook documentation sometimes contains broken (internal) links.
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving
> the generated documentation (Python can trivially do it with '{{python -m
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably
> better) and then a crawler checking for broken links ({{wget}} can easily be
> used for this as described in ARTEMIS-1076 but here again a Java-based
> solution is maybe better).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-1729) Automatically check for broken documentation links
[
https://issues.apache.org/jira/browse/ARTEMIS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836692#comment-17836692
]
Justin Bertram commented on ARTEMIS-1729:
-
Since this Jira was opened the documentation has migrated to AsciiDoc which has
a built-in facility for finding broken internal links. I sent a PR to configure
& use this functionality when generating the docs.
> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Documentation
>Reporter: Lionel Cons
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Artemis GitBook documentation sometimes contains broken (internal) links.
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving
> the generated documentation (Python can trivially do it with '{{python -m
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably
> better) and then a crawler checking for broken links ({{wget}} can easily be
> used for this as described in ARTEMIS-1076 but here again a Java-based
> solution is maybe better).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-1729) Automatically check for broken documentation links
[
https://issues.apache.org/jira/browse/ARTEMIS-1729?focusedWorklogId=914430&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914430
]
ASF GitHub Bot logged work on ARTEMIS-1729:
---
Author: ASF GitHub Bot
Created on: 12/Apr/24 16:05
Start Date: 12/Apr/24 16:05
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #4882:
URL: https://github.com/apache/activemq-artemis/pull/4882
(no comment)
Issue Time Tracking
---
Worklog Id: (was: 914430)
Remaining Estimate: 0h
Time Spent: 10m
> Automatically check for broken documentation links
> --
>
> Key: ARTEMIS-1729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Documentation
>Reporter: Lionel Cons
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Artemis GitBook documentation sometimes contains broken (internal) links.
> See for instance ARTEMIS-1076 or ARTEMIS-1721.
> It would be good to automatically check for broken links as part of the Maven
> {{test}} task.
> One way to do this would be to have a Maven task to run a webserver serving
> the generated documentation (Python can trivially do it with '{{python -m
> SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably
> better) and then a crawler checking for broken links ({{wget}} can easily be
> used for this as described in ARTEMIS-1076 but here again a Java-based
> solution is maybe better).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-702) [Core JMS Client] Violates JMS 2.0 Specification for JMSConsumer receiveBody error handling
[
https://issues.apache.org/jira/browse/ARTEMIS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-702:
--
Assignee: (was: Justin Bertram)
> [Core JMS Client] Violates JMS 2.0 Specification for JMSConsumer receiveBody
> error handling
> ---
>
> Key: ARTEMIS-702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-702
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Timothy A. Bish
>Priority: Minor
>
> The JMS 2.0 Specification for the JMSConsumer#receiveBody methods states the
> following about how in general the methods work and how body conversion or
> failure thereof is handled.
> {quote}
> Receives the next message produced for this JMSConsumer and returns its body
> as an object of the specified type. This method may be used to receive any
> type of message except for StreamMessage and Message, so long as the message
> has a body which is capable of being assigned to the specified type. This
> means that the specified class or interface must either be the same as, or a
> superclass or superinterface of, the class of the message body. If the
> message is not one of the supported types, or its body cannot be assigned to
> the specified type, or it has no body, then a MessageFormatRuntimeException
> is thrown.
> {quote}
> It then goes on to state that for that in the face of a
> MessageFormatRuntimeException the client should do the following:
> {quote}
> AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE: The JMS provider will behave as if
> the unsuccessful call to receiveBody had not occurred. The message will be
> delivered again before any subsequent messages.
> This is not considered to be redelivery and does not cause the JMSRedelivered
> message header field to be set or the JMSXDeliveryCount message property to
> be incremented.
> {quote}
> This does not seem to be the case in the Artemis Core JMS client as the
> following simple test seems to show:
> {code}
>@Test
>public void testJMSConsumerReceiveBodyHandlesMFECorrectly() throws
> Exception {
> final String CONTENT_EXPECTED = "Message-Content";
> JMSContext context = null;
> try {
> context = cf.createContext();
> JMSProducer producer = context.createProducer();
> JMSConsumer consumer = context.createConsumer(topic);
> TextMessage msg = context.createTextMessage(CONTENT_EXPECTED);
> producer.send(topic, msg);
> try {
> consumer.receiveBody(Boolean.class, 2000);
> fail("Should have thrown MessageFormatRuntimeException");
> } catch (MessageFormatRuntimeException mfre) {
> }
> String received = consumer.receiveBody(String.class, 2000);
> Assert.assertNotNull(received);
> Assert.assertEquals(CONTENT_EXPECTED, received);
> } finally {
> if (context != null) {
> context.close();
> }
> }
>}
> {code}
> The specification mandated behaviour is that the message should not be
> acknowledged and continue to be redelivered until such time as the
> receiveBody call actually succeeds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3524) Review Documentation
[ https://issues.apache.org/jira/browse/ARTEMIS-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-3524. - Resolution: Done > Review Documentation > > > Key: ARTEMIS-3524 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3524 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3299) QueueControl: listMessages with page and pageSize
[ https://issues.apache.org/jira/browse/ARTEMIS-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-3299. - Resolution: Won't Do > QueueControl: listMessages with page and pageSize > - > > Key: ARTEMIS-3299 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3299 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: API >Affects Versions: 2.17.0 >Reporter: Raymond >Priority: Minor > > On the QueueControl API the listMessages and listMessagesAsJson only use a > filter as a parameter > ([https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/api/core/management/QueueControl.html#listMessagesAsJSON-java.lang.String-). > ]The browse methods also allow page and pageSize as parameter (as well > combined with a filter). I would like these available as well on listMessages > and listMessagesAsJson. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4
[ https://issues.apache.org/jira/browse/ARTEMIS-4680?focusedWorklogId=914424&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914424 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 12/Apr/24 14:49 Start Date: 12/Apr/24 14:49 Worklog Time Spent: 10m Work Description: andytaylor commented on code in PR #3: URL: https://github.com/apache/activemq-artemis-console-plugin/pull/3#discussion_r1562659257 ## pom.xml: ## @@ -0,0 +1,253 @@ + + +http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> +4.0.0 +org.apache.activemq +artemis-console-plugin +war Review Comment: I have added a root pom and also a source assembly ## pom.xml: ## @@ -0,0 +1,253 @@ + + +http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> +4.0.0 +org.apache.activemq +artemis-console-plugin +war +1.0.0-SNAPSHOT + + +org.apache +apache +23 +org.apache:apache + + +ActiveMQ Artemis Console Plugin + + + +11 +11 + Upgrade the console to use HawtIO 4 > --- > > Key: ARTEMIS-4680 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4680 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > > The current console is based upon HawtIO 1 which in turn is built on > Bootstrap. Bootstrap is old and no longer actively being maintained. > > This improvement is to migrate the current console to use HawtIO 4 which i > based on Typescript, react and Patternfly. > > A WIP can be found > [here|https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9469) Removing JRMS dependency from assembly POM
[
https://issues.apache.org/jira/browse/AMQ-9469?focusedWorklogId=914359&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914359
]
ASF GitHub Bot logged work on AMQ-9469:
---
Author: ASF GitHub Bot
Created on: 12/Apr/24 09:00
Start Date: 12/Apr/24 09:00
Worklog Time Spent: 10m
Work Description: jbonofre commented on PR #1191:
URL: https://github.com/apache/activemq/pull/1191#issuecomment-2051340853
@kartg I cherry-picked the commit for `activemq-5.18.x` branch.
Issue Time Tracking
---
Worklog Id: (was: 914359)
Time Spent: 50m (was: 40m)
> Removing JRMS dependency from assembly POM
> --
>
> Key: AMQ-9469
> URL: https://issues.apache.org/jira/browse/AMQ-9469
> Project: ActiveMQ Classic
> Issue Type: Improvement
> Environment: Tested using the libraries from the ActiveMQ 5.18.3
> tarball downloaded from
> https://activemq.apache.org/components/classic/download/
>Reporter: Kartik Ganesh
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 6.2.0, 6.1.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello!
> I noticed that the ActiveMQ [assembly
> pom.xml|https://github.com/apache/activemq/blob/main/assembly/pom.xml#L484-L486]
> has a dependency on a very old library - "jrms-1.1" - and I'm wondering if
> this can be removed. This library has not seen any releases/updates since
> 2005 and [Maven|https://mvnrepository.com/artifact/jrms/jrms/usages] lists
> only ActiveMQ and Apache Camel as upstream usages.
> After digging through ActiveMQ's mailing lists and commit history, I found
> that it [used to be
> listed|https://github.com/apache/activemq-web/blob/7a7d976c/2004/06/23/jgroups-and-jrms-support.xml]
> on ActiveMQ's [URI
> Protocols|https://activemq.apache.org/components/classic/documentation/uri-protocols]
> page, but was removed at some point. JRMS seems to be listed as a
> peer-to-peer option on the
> [topologies|https://activemq.apache.org/components/classic/documentation/topologies]
> page but is not discussed in either the
> [peer|https://activemq.apache.org/components/classic/documentation/peer-transport-reference]
> or
> [multicast|https://activemq.apache.org/components/classic/documentation/multicast-transport-reference]
> transport reference pages.
> If I try to specify "jrms://" as a protocol for my ActiveMQConnectionFactory,
> I see the following stack-trace:
> {noformat}
> javax.jms.JMSException: Could not create Transport. Reason:
> java.io.IOException: Transport scheme NOT recognized: [jrms]
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:378)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:391)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:349)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:245)
> at App$HelloWorldProducer.run(App.java:66)
> at java.base/java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: Transport scheme NOT recognized: [jrms]
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:30)
> at
> org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:185)
> at
> org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:376)
> ... 5 more
> Caused by: java.io.IOException: Could not find factory class for resource:
> META-INF/services/org/apache/activemq/transport/jrms
> at
> org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.loadProperties(FactoryFinder.java:104)
> at
> org.apache.activemq.util.FactoryFinder$StandaloneObjectFactory.create(FactoryFinder.java:61)
> at
> org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:154)
> at
> org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:182)
> ... 7 more{noformat}
> An [email from 2011 on the users
> mailing-list|https://lists.apache.org/thread/wbwdj8011tmcqtdlbbfmzsthjdrh0gn0]
> came to the same conclusion, but I don't see any further discussion on it.
> I've confirmed that the
> [META-INF/services/org/apache/activemq/transport|https://github.com/apache/activemq/tree/main/activemq-client/src/main/resources/META-INF/services/org/apache/activemq/transport]
> folder under activemq-client does not have a "jrms" file.
--
This message was sent by Atlassian Jira
