[jira] [Updated] (AMQ-8274) Pass sortColumnId and sortOrder to console via url parameters
[ https://issues.apache.org/jira/browse/AMQ-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-8274: Fix Version/s: 6.0.1 (was: 6.0.0) (was: 5.18.3) > Pass sortColumnId and sortOrder to console via url parameters > - > > Key: AMQ-8274 > URL: https://issues.apache.org/jira/browse/AMQ-8274 > Project: ActiveMQ > Issue Type: New Feature > Components: Web Console >Reporter: Max >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 6.0.1 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Pass sortColumnId and sortOrder to console via url parameters. > This is convenient for visual monitoring of dequeued message counts over time. > > Current web console always sorts by name and there is no way to pass > preferred sort order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-8500) JMS 2.0 support for DeliveryTime and DeliveryDelay in openwire
[ https://issues.apache.org/jira/browse/AMQ-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-8500: Fix Version/s: 6.0.1 (was: 6.0.0) > JMS 2.0 support for DeliveryTime and DeliveryDelay in openwire > -- > > Key: AMQ-8500 > URL: https://issues.apache.org/jira/browse/AMQ-8500 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Priority: Major > Labels: #jms2 > Fix For: 6.0.1 > > > Currently, JMSDeliveryDelay and JMSDeliveryTime are not supported in openwire > v12 > Comment added to relevant code: > // TODO: AMQ-8500 - update this when openwire supports JMSDeliveryTime > activemq-client/src/main/java/org/apache/activemq/ActiveMQMessageTransformation.java > [public static void copyProperties(Message fromMessage, Message toMessage) > throws JMSException] > ./activemq-client/src/main/java/org/apache/activemq/ActiveMQSession.java > [protected void send(..)] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9302) Modernize activemq-openwire-generator
[ https://issues.apache.org/jira/browse/AMQ-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-9302: Fix Version/s: 6.0.1 (was: 6.0.0) > Modernize activemq-openwire-generator > - > > Key: AMQ-9302 > URL: https://issues.apache.org/jira/browse/AMQ-9302 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Priority: Minor > Fix For: 6.0.1 > > > 1. Update tooling for JDK 17 > 2. Update tooling to add execution targets based on language desired > 3. Update documentation > ref: Last commit w/ openwire change (v12) > https://github.com/apache/activemq/commit/3953b9aaefaee914bdd0702f27aef47c021ceb27 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-8324) Implement JMS 2.0 MessageProducer CompletionListener methods
[ https://issues.apache.org/jira/browse/AMQ-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-8324: Fix Version/s: 6.0.1 (was: 6.0.0) > Implement JMS 2.0 MessageProducer CompletionListener methods > > > Key: AMQ-8324 > URL: https://issues.apache.org/jira/browse/AMQ-8324 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Labels: #jms2 > Fix For: 6.0.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CompletionListener, etc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9281) Cleanup Camel dependencies
[ https://issues.apache.org/jira/browse/AMQ-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766518#comment-17766518 ] Matt Pavlovich commented on AMQ-9281: - I think a *lot* of people use the shipped camel libraries for jms-bridges, file-to-queue, queue-to-file. I'm not sure we should fully remove. Or at least we should provide an assembly users can extra on top of the apache activemq dist. > Cleanup Camel dependencies > -- > > Key: AMQ-9281 > URL: https://issues.apache.org/jira/browse/AMQ-9281 > Project: ActiveMQ > Issue Type: Task > Components: Camel >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.0.0 > > > As we don't provide activemq-camel component, I think we should remove all > reference to Camel (maybe just keeping few itests, I will check). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-8524) Review flaky unit test activemq-mqtt/MQTTNIOSSLTest
[ https://issues.apache.org/jira/browse/AMQ-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-8524: Fix Version/s: 6.0.1 (was: 6.0.0) (was: 5.18.3) > Review flaky unit test activemq-mqtt/MQTTNIOSSLTest > --- > > Key: AMQ-8524 > URL: https://issues.apache.org/jira/browse/AMQ-8524 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 6.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-8577) Clean-up flaky unit tests
[
https://issues.apache.org/jira/browse/AMQ-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated AMQ-8577:
Fix Version/s: 6.0.1
(was: 6.0.0)
(was: 5.18.3)
> Clean-up flaky unit tests
> -
>
> Key: AMQ-8577
> URL: https://issues.apache.org/jira/browse/AMQ-8577
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Major
> Fix For: 6.0.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following tests are flaky for a variety of reasons
> 1. Appears to lockup
> - JobSchedulerBrokerShutdownTest
> 2. Execution time on "slow" CI causes timeout to be exceeded during peak
> build times
> Full list:
> {noformat}
> **/AMQ4092Test.java
> **/AMQ4351Test.java
> **/AMQ4607Test.java
> **/AMQ4952Test.java
> **/AMQ6432Test.java
> **/DurableSubscriptionInflightMessageSizeTest.java
> **/JDBCIOExceptionHandlerTest.java
> **/OfflineDurableSubscriberTimeoutTest.java
> **/QueueSubscriptionTest.java
> **/RoundRobinDispatchPolicyTest.java
> **/SimpleDispatchPolicyTest.java
> **/JobSchedulerBrokerShutdownTest.java
> **/ProxyConnectorTest.java
> **/DuplexAdvisoryRaceTest.java
> **/JDBCPersistenceAdapterExpiredMessageTest.java
> **/JDBCCleanupLimitedPoolTest.java
> **/PercentDiskUsageLimitTest.java
> **/TwoBrokerMulticastQueueTest.java
> **/RecoveryStatsBrokerTest.java
> **/ClientIdFilterDispatchPolicyTest.java
> **/StartAndConcurrentStopBrokerTest.java
> **/BlobTransferPolicyUriTest.java
> {noformat}
> 3. Fix flaky assembly tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9299) Unknown license gram dependency
[ https://issues.apache.org/jira/browse/AMQ-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated AMQ-9299: Fix Version/s: 6.0.1 (was: 6.0.0) (was: 5.18.3) > Unknown license gram dependency > --- > > Key: AMQ-9299 > URL: https://issues.apache.org/jira/browse/AMQ-9299 > Project: ActiveMQ > Issue Type: Task >Reporter: Henri Yandell >Assignee: Matt Pavlovich >Priority: Trivial > Fix For: 6.0.1 > > > Found an interesting "what's the license?" in this project. > [https://repo1.maven.org/maven2/org/apache/activemq/activemq-openwire-generator/5.18.2/activemq-openwire-generator-5.18.2.pom] > That component is still getting released regularly. It depends on > "org.codehaus.gram-1.1". Which isold. And also without clear license, and > no source code available. It looks like it's a bit of flotsam that happened > during Groovy's early years and if any of it has survived, it has morphed > into something else. > I don't see the source using it. The jar itself only contains: > 3537 10-03-2005 10:01 org/codehaus/gram/Gram.class > 1864 10-03-2005 10:01 org/codehaus/gram/GramModule.class > 2875 10-03-2005 10:01 org/codehaus/gram/GramSupport.class > 4467 10-03-2005 10:01 org/codehaus/gram/GramTask.class > 3318 10-03-2005 10:01 org/codehaus/gram/hibernate/ColumnInfo.class > 2275 10-03-2005 10:01 > org/codehaus/gram/hibernate/HibernateSupport.class > Though reading OPENWIRE-46; it sounds like this entire repo may want to go. > If so...why is this still being released as an artifact? > I originally opened this as OPENWIRE-64 but suggestion on Slack was to open > here as that Jira project was not active. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4270) Messages get lost when using multiple consumers with topic hierarchies
[
https://issues.apache.org/jira/browse/ARTEMIS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4270.
-
Fix Version/s: 2.32.0
Resolution: Fixed
> Messages get lost when using multiple consumers with topic hierarchies
> --
>
> Key: ARTEMIS-4270
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4270
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.24.0
>Reporter: Moritz
>Priority: Major
> Fix For: 2.32.0
>
> Attachments: topic-hierarchies-bug-updated.zip,
> topic-hierarchies-bug.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There is an issue when we have the following setup:
> * Shared durable consumer A listening to *news.#*
> * Shared durable consumer B listening to *news.europe.#*
> * Message M1 sent to *news.europe.sports*
> * Message M2 sent to *news.europe*
> Expected behavior:
> * A receives M1 and M2
> * B receives M1 and M2
> Actual behavior:
> * A receives M1 and M2
> * B receives M1
> This happens when it is run with a clean Artemis, i.e. without any previous
> data. If we run it a second time B receives M1 and M2. When using
> *consumer.receive()* it also works as expected.
>
> This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
> it so I chose the second version I've tested it for. The attached project
> showcases the bug where I simply adjusted the example
> {*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
> I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions
> concerning the topic not being multicast (already with the original example).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4270) Messages get lost when using multiple consumers with topic hierarchies
[
https://issues.apache.org/jira/browse/ARTEMIS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766480#comment-17766480
]
ASF subversion and git services commented on ARTEMIS-4270:
--
Commit 1d3fd650086522bb6da2b3c387f87e300fbca2e5 in activemq-artemis's branch
refs/heads/main from Nicolas Filotto
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1d3fd65008 ]
ARTEMIS-4270 Allow hierarchy of wildcard bindings
In case the bindings "news.#" and "news.europe.#" are registered, only the
first one matches with the address "news.europe" while both are supposed to
match. Those changes are meant to get rid of this limitation.
> Messages get lost when using multiple consumers with topic hierarchies
> --
>
> Key: ARTEMIS-4270
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4270
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.24.0
>Reporter: Moritz
>Priority: Major
> Attachments: topic-hierarchies-bug-updated.zip,
> topic-hierarchies-bug.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There is an issue when we have the following setup:
> * Shared durable consumer A listening to *news.#*
> * Shared durable consumer B listening to *news.europe.#*
> * Message M1 sent to *news.europe.sports*
> * Message M2 sent to *news.europe*
> Expected behavior:
> * A receives M1 and M2
> * B receives M1 and M2
> Actual behavior:
> * A receives M1 and M2
> * B receives M1
> This happens when it is run with a clean Artemis, i.e. without any previous
> data. If we run it a second time B receives M1 and M2. When using
> *consumer.receive()* it also works as expected.
>
> This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
> it so I chose the second version I've tested it for. The attached project
> showcases the bug where I simply adjusted the example
> {*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
> I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions
> concerning the topic not being multicast (already with the original example).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4432) openwire connection failure handling is bypassing the actor and ignoring the operation context leading to contention in error
[ https://issues.apache.org/jira/browse/ARTEMIS-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4432: Fix Version/s: (was: 2.31.0) > openwire connection failure handling is bypassing the actor and ignoring the > operation context leading to contention in error > - > > Key: ARTEMIS-4432 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4432 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > On a kill -9 test, for a transacted batch openwire consumer, it is possibly > for a batch to get stuck in delivery due to contention on the current > transaction. A restart is needed to have redeliver happen in this case. > The contention can be avoided by respecting the ordered actor and operation > context in the fail handling that originates from the netty handler when a > connection dies due to socket error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4432) openwire connection failure handling is bypassing the actor and ignoring the operation context leading to contention in error
Gary Tully created ARTEMIS-4432: --- Summary: openwire connection failure handling is bypassing the actor and ignoring the operation context leading to contention in error Key: ARTEMIS-4432 URL: https://issues.apache.org/jira/browse/ARTEMIS-4432 Project: ActiveMQ Artemis Issue Type: Bug Components: OpenWire Affects Versions: 2.30.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.31.0 On a kill -9 test, for a transacted batch openwire consumer, it is possibly for a batch to get stuck in delivery due to contention on the current transaction. A restart is needed to have redeliver happen in this case. The contention can be avoided by respecting the ordered actor and operation context in the fail handling that originates from the netty handler when a connection dies due to socket error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
