[jira] [Work logged] (ARTEMIS-4239) use StandardCharsets.UTF_8
[ https://issues.apache.org/jira/browse/ARTEMIS-4239?focusedWorklogId=856265=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856265 ] ASF GitHub Bot logged work on ARTEMIS-4239: --- Author: ASF GitHub Bot Created on: 11/Apr/23 21:18 Start Date: 11/Apr/23 21:18 Worklog Time Spent: 10m Work Description: amarkevich commented on PR #4431: URL: https://github.com/apache/activemq-artemis/pull/4431#issuecomment-1504105832 > limit the changes done Issue Time Tracking --- Worklog Id: (was: 856265) Time Spent: 20m (was: 10m) > use StandardCharsets.UTF_8 > -- > > Key: ARTEMIS-4239 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4239 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.28.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > avoid UnsupportedEncodingException handling -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
[
https://issues.apache.org/jira/browse/ARTEMIS-4212?focusedWorklogId=856212=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856212
]
ASF GitHub Bot logged work on ARTEMIS-4212:
---
Author: ASF GitHub Bot
Created on: 11/Apr/23 19:10
Start Date: 11/Apr/23 19:10
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4421:
URL: https://github.com/apache/activemq-artemis/pull/4421#discussion_r1163222863
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ServerSession.java:
##
@@ -111,7 +112,7 @@ public interface ServerSession extends SecurityAuth {
void addCloseable(Closeable closeable);
- boolean checkAutoCreate(SimpleString address, RoutingType routingType)
throws Exception;
+ AutoCreateResult checkAutoCreate(QueueConfiguration queueConfiguration)
throws Exception;
Review Comment:
I'll try to simplify it.
Issue Time Tracking
---
Worklog Id: (was: 856212)
Time Spent: 2h 40m (was: 2.5h)
> Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
> ---
>
> Key: ARTEMIS-4212
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4212
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When the routing type of an address (and associated queue) does not match the
> routing type of a client producer, the resultant behavior is a bit unexpected.
> Expected Behavior:
> If a client sends a message to an address / queue with the same name, but a
> different routing type, the expected behavior would be to throw some sort of
> InvalidDestinationException (if auto-create is not enabled), or to create the
> matching address and queue with the appropriate routing type. The routing
> count on the existing address (with non-matching routing type) should remain
> unchanged.
> Actual Behavior:
> When sending, for example, to a predefined anycast address and queue from a
> multiccast (Topic) producer, the routed count on the address is incremented,
> but the message count on the matching queue is not. No indication is given at
> the client end that the messages failed to get routed - they are silently
> dropped.
> This is reproducible using a qpid / proton queue producer to send to a
> multicast address or using a topic producer to send to an anycast address,
> e.g.:
> 1. Create a a broker, setting auto-create-queues and auto-create addresses to
> "false" for the catch-all address-setting
> 2. Start the broker and create a an address and matching queue with a ANYCAST
> routing type
> 3. Send 1000 messages to the broker using the same queue name but mismatched
> routing type:
> {code}
> ./artemis producer --url amqp://localhost:61616 --user admin --password admin
> --destination topic://{QUEUE NAME} --protocol amqp
> {code}
> No error is emitted and the routing count is incremented by 1000 at the
> address level, but remains unchanged at the destination level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[
https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=856206=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856206
]
ASF GitHub Bot logged work on ARTEMIS-4238:
---
Author: ASF GitHub Bot
Created on: 11/Apr/23 18:46
Start Date: 11/Apr/23 18:46
Worklog Time Spent: 10m
Work Description: ehsavoie commented on code in PR #4433:
URL: https://github.com/apache/activemq-artemis/pull/4433#discussion_r1163199931
##
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/ActiveMQRAManagedConnection.java:
##
@@ -336,7 +336,7 @@ public void associateConnection(final Object obj) throws
ResourceException {
public void checkTransactionActive() throws JMSException {
// don't bother looking at the transaction if there's an active XID
- if (!inManagedTx && tsr != null) {
+ if (!inManagedTx && tsr != null && tsr.getTransactionKey() != null) {
Review Comment:
a leftover
Issue Time Tracking
---
Worklog Id: (was: 856206)
Time Spent: 50m (was: 40m)
> transaction timeout ActivationConfigProperty is no longer working
> -
>
> Key: ARTEMIS-4238
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4238
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.28.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> ARTEMIS-3707 has created a regression where the transactionTimeout
> ActivationConfigProperty is no longer working properly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[ https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=856196=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856196 ] ASF GitHub Bot logged work on ARTEMIS-4238: --- Author: ASF GitHub Bot Created on: 11/Apr/23 17:58 Start Date: 11/Apr/23 17:58 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4433: URL: https://github.com/apache/activemq-artemis/pull/4433#issuecomment-1503849936 The commit message doesn't follow the [recommended format](https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/en/code.md#commitMessageDetails). There's no need for square brackets and a colon around the Jira reference. Issue Time Tracking --- Worklog Id: (was: 856196) Time Spent: 40m (was: 0.5h) > transaction timeout ActivationConfigProperty is no longer working > - > > Key: ARTEMIS-4238 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4238 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.28.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > ARTEMIS-3707 has created a regression where the transactionTimeout > ActivationConfigProperty is no longer working properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[ https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=856193=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856193 ] ASF GitHub Bot logged work on ARTEMIS-4238: --- Author: ASF GitHub Bot Created on: 11/Apr/23 17:56 Start Date: 11/Apr/23 17:56 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4433: URL: https://github.com/apache/activemq-artemis/pull/4433#issuecomment-1503847900 It would be ideal to have some tests for this to catch future regressions. Issue Time Tracking --- Worklog Id: (was: 856193) Time Spent: 0.5h (was: 20m) > transaction timeout ActivationConfigProperty is no longer working > - > > Key: ARTEMIS-4238 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4238 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.28.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > ARTEMIS-3707 has created a regression where the transactionTimeout > ActivationConfigProperty is no longer working properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[
https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=856192=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856192
]
ASF GitHub Bot logged work on ARTEMIS-4238:
---
Author: ASF GitHub Bot
Created on: 11/Apr/23 17:55
Start Date: 11/Apr/23 17:55
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4433:
URL: https://github.com/apache/activemq-artemis/pull/4433#discussion_r1163154561
##
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/ActiveMQRAManagedConnection.java:
##
@@ -336,7 +336,7 @@ public void associateConnection(final Object obj) throws
ResourceException {
public void checkTransactionActive() throws JMSException {
// don't bother looking at the transaction if there's an active XID
- if (!inManagedTx && tsr != null) {
+ if (!inManagedTx && tsr != null && tsr.getTransactionKey() != null) {
Review Comment:
This change doesn't appear related to the `transactionTimeout` change. Why
is this necessary?
Issue Time Tracking
---
Worklog Id: (was: 856192)
Time Spent: 20m (was: 10m)
> transaction timeout ActivationConfigProperty is no longer working
> -
>
> Key: ARTEMIS-4238
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4238
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.28.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ARTEMIS-3707 has created a regression where the transactionTimeout
> ActivationConfigProperty is no longer working properly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[
https://issues.apache.org/jira/browse/ARTEMIS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711076#comment-17711076
]
Justin Bertram commented on ARTEMIS-4238:
-
For what it's worth the functionality of the {{transactionTimeout}} activation
configuration property was removed _on purpose_ due to the fact that the RA was
using the transaction manager to set the timeout. This was reported via
ARTEMIS-3707 and ARTEMIS-1487. The transaction manager is to be used by the
*application server* and not by components like resource adapters. Java/Jakarta
EE servers can and should have a way to set the transaction timeout for EJBs in
general and MDBs in particular.
That said, I can appreciate that some users rely on this behavior so it
arguably should have been deprecated and removed later instead of having the
functionality removed completely all at once.
> transaction timeout ActivationConfigProperty is no longer working
> -
>
> Key: ARTEMIS-4238
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4238
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.28.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ARTEMIS-3707 has created a regression where the transactionTimeout
> ActivationConfigProperty is no longer working properly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4239) use StandardCharsets.UTF_8
[ https://issues.apache.org/jira/browse/ARTEMIS-4239?focusedWorklogId=856147=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856147 ] ASF GitHub Bot logged work on ARTEMIS-4239: --- Author: ASF GitHub Bot Created on: 11/Apr/23 14:55 Start Date: 11/Apr/23 14:55 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4431: URL: https://github.com/apache/activemq-artemis/pull/4431#issuecomment-1503530207 The change seems to be more expansive than the short title might imply perhaps either limit the changes or provide more context into what and why this is being done Issue Time Tracking --- Worklog Id: (was: 856147) Remaining Estimate: 0h Time Spent: 10m > use StandardCharsets.UTF_8 > -- > > Key: ARTEMIS-4239 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4239 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.28.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > avoid UnsupportedEncodingException handling -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4239) use StandardCharsets.UTF_8
Alexey Markevich created ARTEMIS-4239: - Summary: use StandardCharsets.UTF_8 Key: ARTEMIS-4239 URL: https://issues.apache.org/jira/browse/ARTEMIS-4239 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.28.0 Reporter: Alexey Markevich avoid UnsupportedEncodingException handling -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4171) Potential large message file leak
[
https://issues.apache.org/jira/browse/ARTEMIS-4171?focusedWorklogId=856141=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856141
]
ASF GitHub Bot logged work on ARTEMIS-4171:
---
Author: ASF GitHub Bot
Created on: 11/Apr/23 14:16
Start Date: 11/Apr/23 14:16
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4430:
URL: https://github.com/apache/activemq-artemis/pull/4430#discussion_r1162887459
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/ServerSessionPacketHandler.java:
##
@@ -1130,14 +1130,16 @@ private void sendContinuations(final int packetSize,
try {
session.send(session.getCurrentTransaction(),
EmbedMessageUtil.extractEmbedded((ICoreMessage) message.toMessage(),
storageManager), false, producers.get(senderID), false);
-} catch (Exception e) {
- message.deleteFile();
- throw e;
} catch (Throwable e) {
-
logger.warn("");
- logger.warn("Throwable on currentLargeMessage {}",
message.getMessageID(), e);
-
logger.warn("");
-
+ logger.warn(e.getMessage(), e);
Review Comment:
The code this method is calling looks to throw exceptions in fairly
'typical' situations, e.g security checks, disk usage checks. I think starting
to log a full stacktrace for every one of them, when it specifically didnt
before (presumably as the code calling this method should either handle, or
itself print, them), is likely asking for a lot of new questions. Along the
lines of the more typical 'I suddenly got this new error \'.
Issue Time Tracking
---
Worklog Id: (was: 856141)
Time Spent: 1h (was: 50m)
> Potential large message file leak
> -
>
> Key: ARTEMIS-4171
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4171
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> If an exception is thrown during the sending of a large message (e.g. from a
> plugin) the large message file can be orphaned on disk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[ https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=856139=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856139 ] ASF GitHub Bot logged work on ARTEMIS-4238: --- Author: ASF GitHub Bot Created on: 11/Apr/23 14:13 Start Date: 11/Apr/23 14:13 Worklog Time Spent: 10m Work Description: ehsavoie opened a new pull request, #4433: URL: https://github.com/apache/activemq-artemis/pull/4433 …nger working. * Re-adding the missing code Jira: https://issues.apache.org/jira/browse/ARTEMIS-4238 Issue Time Tracking --- Worklog Id: (was: 856139) Remaining Estimate: 0h Time Spent: 10m > transaction timeout ActivationConfigProperty is no longer working > - > > Key: ARTEMIS-4238 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4238 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.28.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > ARTEMIS-3707 has created a regression where the transactionTimeout > ActivationConfigProperty is no longer working properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9242) activemq-partition module should not have a compile time dependency on log4j-slf4j2-impl
[ https://issues.apache.org/jira/browse/AMQ-9242?focusedWorklogId=856138=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856138 ] ASF GitHub Bot logged work on AMQ-9242: --- Author: ASF GitHub Bot Created on: 11/Apr/23 14:10 Start Date: 11/Apr/23 14:10 Worklog Time Spent: 10m Work Description: cshannon commented on PR #997: URL: https://github.com/apache/activemq/pull/997#issuecomment-1503434232 I meant to get this into 5.18.1 but forgot but it's fine to wait for 5.18.2 as it's been broken a while, not a new thing and this module isn't really used anymore anyways. Issue Time Tracking --- Worklog Id: (was: 856138) Remaining Estimate: 0h Time Spent: 10m > activemq-partition module should not have a compile time dependency on > log4j-slf4j2-impl > > > Key: AMQ-9242 > URL: https://issues.apache.org/jira/browse/AMQ-9242 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.19.0, 5.18.2 > > Time Spent: 10m > Remaining Estimate: 0h > > The activemq-partition module is pulling in log4j-slf4j2-impl by mistake as a > compile time dependency. It should only be a test dependency and the > slf4j-api should be the only compile time dependency like the rest of the > modules. Only the activemq-all and assembly modules should pull in the > implementation versions. > This has been broken since before slf4j2 but I noticed it with the upgrade > from conflicts when I had slff4j1 still on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AMQ-9242) activemq-partition module should not have a compile time dependency on log4j-slf4j2-impl
[ https://issues.apache.org/jira/browse/AMQ-9242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reassigned AMQ-9242: --- Assignee: Christopher L. Shannon > activemq-partition module should not have a compile time dependency on > log4j-slf4j2-impl > > > Key: AMQ-9242 > URL: https://issues.apache.org/jira/browse/AMQ-9242 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.19.0, 5.18.2 > > > The activemq-partition module is pulling in log4j-slf4j2-impl by mistake as a > compile time dependency. It should only be a test dependency and the > slf4j-api should be the only compile time dependency like the rest of the > modules. Only the activemq-all and assembly modules should pull in the > implementation versions. > This has been broken since before slf4j2 but I noticed it with the upgrade > from conflicts when I had slff4j1 still on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9242) activem-partition should not have a compile time dependency on log4j-slf4j2-impl
Christopher L. Shannon created AMQ-9242: --- Summary: activem-partition should not have a compile time dependency on log4j-slf4j2-impl Key: AMQ-9242 URL: https://issues.apache.org/jira/browse/AMQ-9242 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: Christopher L. Shannon Fix For: 5.19.0, 5.18.2 The activemq-partition module is pulling in log4j-slf4j2-impl by mistake as a compile time dependency. It should only be a test dependency and the slf4j-api should be the only compile time dependency like the rest of the modules. Only the activemq-all and assembly modules should pull in the implementation versions. This has been broken since before slf4j2 but I noticed it with the upgrade from conflicts when I had slff4j1 still on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9242) activemq-partition module should not have a compile time dependency on log4j-slf4j2-impl
[ https://issues.apache.org/jira/browse/AMQ-9242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-9242: Summary: activemq-partition module should not have a compile time dependency on log4j-slf4j2-impl (was: activem-partition should not have a compile time dependency on log4j-slf4j2-impl) > activemq-partition module should not have a compile time dependency on > log4j-slf4j2-impl > > > Key: AMQ-9242 > URL: https://issues.apache.org/jira/browse/AMQ-9242 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Christopher L. Shannon >Priority: Major > Fix For: 5.19.0, 5.18.2 > > > The activemq-partition module is pulling in log4j-slf4j2-impl by mistake as a > compile time dependency. It should only be a test dependency and the > slf4j-api should be the only compile time dependency like the rest of the > modules. Only the activemq-all and assembly modules should pull in the > implementation versions. > This has been broken since before slf4j2 but I noticed it with the upgrade > from conflicts when I had slff4j1 still on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4171) Potential large message file leak
[
https://issues.apache.org/jira/browse/ARTEMIS-4171?focusedWorklogId=856123=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856123
]
ASF GitHub Bot logged work on ARTEMIS-4171:
---
Author: ASF GitHub Bot
Created on: 11/Apr/23 13:21
Start Date: 11/Apr/23 13:21
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4430:
URL: https://github.com/apache/activemq-artemis/pull/4430#discussion_r1162809029
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/ServerSessionPacketHandler.java:
##
@@ -1130,14 +1130,16 @@ private void sendContinuations(final int packetSize,
try {
session.send(session.getCurrentTransaction(),
EmbedMessageUtil.extractEmbedded((ICoreMessage) message.toMessage(),
storageManager), false, producers.get(senderID), false);
-} catch (Exception e) {
- message.deleteFile();
- throw e;
} catch (Throwable e) {
-
logger.warn("");
- logger.warn("Throwable on currentLargeMessage {}",
message.getMessageID(), e);
-
logger.warn("");
-
+ logger.warn(e.getMessage(), e);
Review Comment:
I thought the system was not really supposed to throw an exception at this
stage, and logging it would be only beneficial to finding what's going in a
production system.
I'm dealing with other cases where it's being hard to identify issues, and I
was trying to avoid that pattern here.
One thing is sending an expected exception to the client... (expected as
it's something related to the client's configuration...etc..) the other is a
server's exception not logging anything and only the client being informed
about it.
Issue Time Tracking
---
Worklog Id: (was: 856123)
Time Spent: 50m (was: 40m)
> Potential large message file leak
> -
>
> Key: ARTEMIS-4171
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4171
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If an exception is thrown during the sending of a large message (e.g. from a
> plugin) the large message file can be orphaned on disk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
[
https://issues.apache.org/jira/browse/ARTEMIS-4212?focusedWorklogId=856119=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-856119
]
ASF GitHub Bot logged work on ARTEMIS-4212:
---
Author: ASF GitHub Bot
Created on: 11/Apr/23 13:11
Start Date: 11/Apr/23 13:11
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4421:
URL: https://github.com/apache/activemq-artemis/pull/4421#discussion_r1162547033
##
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/QueueConfiguration.java:
##
@@ -301,6 +338,7 @@ public QueueConfiguration setName(SimpleString name) {
if (CompositeAddress.isFullyQualified(name)) {
this.name = CompositeAddress.extractQueueName(name);
this.address = CompositeAddress.extractAddressName(name);
+ this.fqqn = true;
Review Comment:
setAddress seems like it should have a similar update since it also does the
isFullyQualified check and can change the name and address values like this
method. (This also points to some missing unit tests that should be added).
Should probably use Boolean.TRUE given the field is Boolean (EDIT: or change
field to boolean as in next comment).
##
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/QueueConfiguration.java:
##
@@ -607,6 +645,16 @@ public QueueConfiguration setAutoCreated(Boolean
autoCreated) {
return this;
}
+ /**
+* Based on if the name or address uses FQQN when set
+*
+* defaults to {@code false}
+* @return
+*/
+ public Boolean isFqqn() {
+ return fqqn == null ? false : fqqn;
Review Comment:
The return type is Boolean so it should probably use Boolean.FALSE for the
return, but given it goes to the effort of trying not to return null anyway,
changing the field and return type to primitive boolean would probably be nicer.
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/ProtonServerReceiverContext.java:
##
@@ -174,7 +174,7 @@ private RoutingType getRoutingType(Symbol[] symbols,
SimpleString address) {
}
RoutingType defaultRoutingType =
sessionSPI.getDefaultRoutingType(address);
defaultRoutingType = defaultRoutingType == null ?
ActiveMQDefaultConfiguration.getDefaultRoutingType() : defaultRoutingType;
- return defaultRoutingType;
+ return sessionSPI.getRoutingTypeFromPrefix(address, defaultRoutingType);
Review Comment:
This is changing the behaviour for a producer, but the consumer side hasnt
changed. If we did change this, then I'd expect there should be analogous
changes being made in ProtonServerSenderContext or the producer and consumer
side behaviour could become inconsistent \[again, as they were until recent
changes from Tim (e.g
https://github.com/apache/activemq-artemis/commit/ca66028b2a596a4ab5a61ec57633fed3e7b85b22)
\].
##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/BrokerDefinedMulticastConsumerTest.java:
##
@@ -65,8 +75,6 @@ public void testConsumeFromSingleQueueOnAddressSameName()
throws Exception {
public void testConsumeWhenOnlyAnycast() throws Exception {
server.addAddressInfo(new AddressInfo(address, RoutingType.ANYCAST));
- sendMessages(address.toString(), 1);
-
Review Comment:
Is this removed due to disabling the autocreation? Creating the anycast
queue if needed might be the better change than removing the send. I believe it
was probably there to show attaching to the address worked, before the later
expected failure when attaching the consumer to the same address, due to
explicitly requesting a 'topic / multicast' address and finds the anycast
address instead.
##
artemis-junit/artemis-junit-4/src/test/java/org/apache/activemq/artemis/junit/EmbeddedActiveMQResourceCustomConfigurationTest.java:
##
@@ -38,13 +38,16 @@ public class
EmbeddedActiveMQResourceCustomConfigurationTest {
static final String TEST_ADDRESS = "test.address";
QueueConfiguration queueConfiguration = new
QueueConfiguration(TEST_QUEUE).setAddress(TEST_ADDRESS);
- Configuration customConfiguration = new
ConfigurationImpl().setPersistenceEnabled(false).setSecurityEnabled(true).addQueueConfiguration(queueConfiguration);
+ Configuration customConfiguration = new
ConfigurationImpl().setPersistenceEnabled(false).setSecurityEnabled(true).addQueueConfiguration(queueConfiguration).addAcceptorConfiguration("amqp",
"tcp://localhost:5672");
Review Comment:
Is this change related? The test itself didnt seem to change, and so doesn't
seem to do anything with AMQP?
##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpSendReceiveTest.java:
##
@@ -81,9 +82,9 @@
