[jira] [Resolved] (ARTEMIS-2191) Makes PostOfficeImpl::route common paths inlineable
[ https://issues.apache.org/jira/browse/ARTEMIS-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2191. - Resolution: Abandoned > Makes PostOfficeImpl::route common paths inlineable > --- > > Key: ARTEMIS-2191 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2191 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.7.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > PostOfficeImpl::route is handling very difference cases (eg not > durable/durable messages, not durable/durable queues, transactions etc etc) > on the same code paths, making the code too big to be inlined when specific > code paths are needed. > The code could be refactored to allow better inlining by using smaller > methods and moving away uncommon/slow path from the common one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-1921) Setting client ID on core JMS should be reflected in broker RemotingConnection
[ https://issues.apache.org/jira/browse/ARTEMIS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-1921: --- Assignee: Justin Bertram > Setting client ID on core JMS should be reflected in broker RemotingConnection > -- > > Key: ARTEMIS-1921 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1921 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.1 >Reporter: Johan Stenberg >Assignee: Justin Bertram >Priority: Major > Attachments: Artemis1921_CoreJmsClient_SetClientId_Test.java > > Time Spent: 10m > Remaining Estimate: 0h > > As opposite to Qpid JMS Client over AMPQ1.0 or FuseSource StompJMS client > over STOMP, a clientID set on the JMS ConnectionFactory or the Connection in > the Artemis JMS Client is not available on the broker via > RemotingConnection#getClientID(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-2077) Split-Brain Resolution When Connection Is Regained
[ https://issues.apache.org/jira/browse/ARTEMIS-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2077. - Resolution: Won't Do This should be moot with the new pluggable lock manager implementation using ZooKeeper. > Split-Brain Resolution When Connection Is Regained > -- > > Key: ARTEMIS-2077 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2077 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Ilkka Virolainen >Priority: Major > Fix For: 2.6.2 > > > When the master node in a replicating master/slave pair is congested or > isolated, a failover occurs resulting in split brain. As the cluster > connection is regained, failback should occur to mitigate the situation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-2042) Wrong classLoader used in hornetq RA Reconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2042. - Resolution: Cannot Reproduce > Wrong classLoader used in hornetq RA Reconnect > -- > > Key: ARTEMIS-2042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2042 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.5 >Reporter: Brad Maxwell >Priority: Major > > The re-activation on hornetq, is using the wrong classLoader. > This is because a new Thread is started instead of using the WorkManager from > the ResourceAdapter. > How reproducible: > You could visually verify the classLoader used. This had issues in production > for a customer after failover, and we couldn't replicate the exact > classNotFoundException they had but we could assert the wrong classLoader i > used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-2122) Correct producer identification
[ https://issues.apache.org/jira/browse/ARTEMIS-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2122. - Resolution: Duplicate > Correct producer identification > --- > > Key: ARTEMIS-2122 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2122 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: Broker, OpenWire >Affects Versions: 2.6.3 >Reporter: Pawel >Priority: Minor > > Hi, > It looks, that Artemis is unable to identify producers, connected with > standard ActiveMQ client (org.apache.activemq.ActiveMQConnectionFactory) > instead of Artemis client > (org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory). In this > case, all clients are visible as consumer. > I understand, that You probably supports only dedicated Artemis client, but > compatibility with ActiveMQ client would be great feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838403#comment-17838403 ] ASF subversion and git services commented on ARTEMIS-4723: -- Commit 31243b10239184602a30749be8d83091e1e68c34 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=31243b1023 ] ARTEMIS-4723 Optimization on HandlerBase No need to create a new instance every time the processor starts executing. The instance of counter can be reused and stored in the Thread. > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-4726: --- Assignee: Justin Bertram > Removing scheduled message from queue via management can cause negative > message count > - > > Key: ARTEMIS-4726 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4726 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.31.0 > Environment: NAME="Oracle Linux Server" > VERSION="8.6" > ID="ol" > ID_LIKE="fedora" > VARIANT="Server" > VARIANT_ID="server" > VERSION_ID="8.6" > PLATFORM_ID="platform:el8" > PRETTY_NAME="Oracle Linux Server 8.6" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:oracle:linux:8:6:server" > HOME_URL="https://linux.oracle.com/; > BUG_REPORT_URL="https://bugzilla.oracle.com/; > ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" > ORACLE_BUGZILLA_PRODUCT_VERSION=8.6 > ORACLE_SUPPORT_PRODUCT="Oracle Linux" > ORACLE_SUPPORT_PRODUCT_VERSION=8.6 > > java version "17.0.8" 2023-07-18 LTS > Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14) > Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing) > > > >Reporter: Juanjo Marin >Assignee: Justin Bertram >Priority: Minor > Attachments: Queue1.PNG, Queue2.PNG, Queue3.PNG, RemoveMessage1.PNG, > RemoveMessage2.PNG, listScheduledMessage.PNG, listScheduledMessage.txt, > listScheduledMessages2.txt, removeAll.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > When we delete a scheduled message that has not yet been sent, it subtracts 2 > from the message counter. This only happens when the message has not been > delivered. The queue counter does not recover at any point, but the queue > continues to function normally. > If we remove all messages, the remaining ones are deleted, but the queue goes > into negative. In one of our tests, the queue stopped functioning correctly > and only messages could be inserted; it did not allow consuming them in any > way. We haven't been able to reproduce it again. > I attach screenshots and evidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?focusedWorklogId=915201=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915201 ] ASF GitHub Bot logged work on ARTEMIS-4726: --- Author: ASF GitHub Bot Created on: 17/Apr/24 22:05 Start Date: 17/Apr/24 22:05 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4894: URL: https://github.com/apache/activemq-artemis/pull/4894 (no comment) Issue Time Tracking --- Worklog Id: (was: 915201) Remaining Estimate: 0h Time Spent: 10m > Removing scheduled message from queue via management can cause negative > message count > - > > Key: ARTEMIS-4726 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4726 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.31.0 > Environment: NAME="Oracle Linux Server" > VERSION="8.6" > ID="ol" > ID_LIKE="fedora" > VARIANT="Server" > VARIANT_ID="server" > VERSION_ID="8.6" > PLATFORM_ID="platform:el8" > PRETTY_NAME="Oracle Linux Server 8.6" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:oracle:linux:8:6:server" > HOME_URL="https://linux.oracle.com/; > BUG_REPORT_URL="https://bugzilla.oracle.com/; > ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" > ORACLE_BUGZILLA_PRODUCT_VERSION=8.6 > ORACLE_SUPPORT_PRODUCT="Oracle Linux" > ORACLE_SUPPORT_PRODUCT_VERSION=8.6 > > java version "17.0.8" 2023-07-18 LTS > Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14) > Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing) > > > >Reporter: Juanjo Marin >Priority: Minor > Attachments: Queue1.PNG, Queue2.PNG, Queue3.PNG, RemoveMessage1.PNG, > RemoveMessage2.PNG, listScheduledMessage.PNG, listScheduledMessage.txt, > listScheduledMessages2.txt, removeAll.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > When we delete a scheduled message that has not yet been sent, it subtracts 2 > from the message counter. This only happens when the message has not been > delivered. The queue counter does not recover at any point, but the queue > continues to function normally. > If we remove all messages, the remaining ones are deleted, but the queue goes > into negative. In one of our tests, the queue stopped functioning correctly > and only messages could be inserted; it did not allow consuming them in any > way. We haven't been able to reproduce it again. > I attach screenshots and evidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4726) Removing scheduled message from queue via management can cause negative message count
[ https://issues.apache.org/jira/browse/ARTEMIS-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4726: Summary: Removing scheduled message from queue via management can cause negative message count (was: removeMessage(long) in the Joloquia API fails when the message is scheduled and has not been sent) > Removing scheduled message from queue via management can cause negative > message count > - > > Key: ARTEMIS-4726 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4726 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.31.0 > Environment: NAME="Oracle Linux Server" > VERSION="8.6" > ID="ol" > ID_LIKE="fedora" > VARIANT="Server" > VARIANT_ID="server" > VERSION_ID="8.6" > PLATFORM_ID="platform:el8" > PRETTY_NAME="Oracle Linux Server 8.6" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:oracle:linux:8:6:server" > HOME_URL="https://linux.oracle.com/; > BUG_REPORT_URL="https://bugzilla.oracle.com/; > ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" > ORACLE_BUGZILLA_PRODUCT_VERSION=8.6 > ORACLE_SUPPORT_PRODUCT="Oracle Linux" > ORACLE_SUPPORT_PRODUCT_VERSION=8.6 > > java version "17.0.8" 2023-07-18 LTS > Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14) > Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build > 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing) > > > >Reporter: Juanjo Marin >Priority: Minor > Attachments: Queue1.PNG, Queue2.PNG, Queue3.PNG, RemoveMessage1.PNG, > RemoveMessage2.PNG, listScheduledMessage.PNG, listScheduledMessage.txt, > listScheduledMessages2.txt, removeAll.PNG > > > When we delete a scheduled message that has not yet been sent, it subtracts 2 > from the message counter. This only happens when the message has not been > delivered. The queue counter does not recover at any point, but the queue > continues to function normally. > If we remove all messages, the remaining ones are deleted, but the queue goes > into negative. In one of our tests, the queue stopped functioning correctly > and only messages could be inserted; it did not allow consuming them in any > way. We haven't been able to reproduce it again. > I attach screenshots and evidence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic reassigned ARTEMIS-4723: Assignee: Clebert Suconic > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4723. Resolution: Fixed > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-4723: - Fix Version/s: 2.34.0 > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?focusedWorklogId=915186=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915186 ] ASF GitHub Bot logged work on ARTEMIS-4723: --- Author: ASF GitHub Bot Created on: 17/Apr/24 18:19 Start Date: 17/Apr/24 18:19 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4880: URL: https://github.com/apache/activemq-artemis/pull/4880 Issue Time Tracking --- Worklog Id: (was: 915186) Time Spent: 1h (was: 50m) > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838344#comment-17838344 ] ASF subversion and git services commented on ARTEMIS-4723: -- Commit e4a6687cd46421cf4fc89c3fa941f439772b6d29 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e4a6687cd4 ] ARTEMIS-4723 Avoid objects left on ThreadLocal from OrderedExecutorFactory co-authored: Jakob van Kruijssen > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4719) Artemis Metrics plugin reports wrong data
[
https://issues.apache.org/jira/browse/ARTEMIS-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838295#comment-17838295
]
Justin Bertram commented on ARTEMIS-4719:
-
bq. This plugin only reads the `artemis.message.count` metric, renames to
`eesb.message.count` and add a few tags for monitoring purpose. There is no
aggregation and its single value per address.
I'm still confused. *Every* queue reports {{artemis.message.count}} - only with
a different {{address}} and {{queue}} tag. Is your plugin taking this into
account? Can you share you plugin source code? At this point I'm likely to
resolve this Jira as "Cannot Reproduce" and chalk it up to your plugin.
> Artemis Metrics plugin reports wrong data
> -
>
> Key: ARTEMIS-4719
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4719
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Mohanavalli A
>Priority: Minor
> Attachments: 6m peak.png, image-2024-04-10-12-46-10-394.png
>
>
> We are using an Artemis broker metrics plugin to monitor the message count on
> each address of the broker. Recently we have noticed that the plugin reported
> values which were not realistic and not matching with any of our other
> monitoring information available.
> !6m peak.png|width=502,height=471!
> For a particular address, the plugin reported below values every minute. The
> messages count increase from 437k to 5million and 451K to 6million and a fall
> from 6M to 462 K are not realistic considering the producer/consumers
> capacity. From the values 5M and 6M look to be fake values.
> !image-2024-04-10-12-46-10-394.png|width=211,height=429!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4716) Improve Jakarta Messaging / JMS documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838280#comment-17838280
]
Justin Bertram edited comment on ARTEMIS-4716 at 4/17/24 4:36 PM:
--
bq. There is no such thing as "Jakarta SE", only "Jakarta EE".
There may be no such thing as _Jakarta SE_ per se, but the most common
JMS/Jakarta Messaging use-case is in a Java SE context (i.e. not in an EE
container). This use-case involves basic clients sending and receiving messages
and includes frameworks like Spring. Clients still use Jakarta classes in this
Java SE context. The {{artemis-jakarta-client}} (which is based on the
{{artemis-jms-client}}) is provided to users for this purpose. The presence of
_jakarta_ in the name of the package does *not* equate to _EE_. Classes in the
{{jakarta}} namespace (and the {{javax}} namespace before it) have always been
viable in a Java SE context.
bq. Your package being named "jakarta" is where all my expectations come from...
I'm not 100% clear on what your expectations were, but as this conversation
continues it seems perhaps your expectations were misplaced.
bq. And a library author should value convenience, don't you think?
In general, I agree. Convenience should be valued. However, as with all things
it must be balanced with other priorities, some of which may actually compete
directly with convenience, but I digress.
bq. In any event, CDI or JNDI, I'm not picky, as long as there are clear
instructions stating the preferred way to use the library.
>From an implementer's perspective I'm not sure there is a clear preference.
>I'd say use whichever best fits your use-case.
bq. I don't think I can quite use WildFly as a template to integrate
"artemis-jakarta-client" in my application, can I?
You can't use it as a _template_ per se, but it's worth noting how WildFly
manages the integration. Most of the "hundreds and hundreds of lines" of code
you saw deals with configuring and managing the embedded broker. That's not
particularly relevant to your use-case. The main things it does to help EE
applications directly are (1) deploying the ActiveMQ Artemis JCA RA (which
enables MDB use-cases and provides connection pooling and XA support for any
messaging client running in the container) and (2) binding connection factories
into JNDI (which mainly enable connectivity from remote messaging clients).
There are some more nuances in there, but those are the main two things that
would impact someone in your situation. These are the kinds of things you'd
want to configure on _any_ application server with regards to messaging
integration.
bq. What I meant is, does any project using a Jakarta EE implementation (one
that doesn't already come with ActiveMQ, obviously) ever used
"artemis-jakarta-client" with dependency injection (or even at all)?
I can't say for sure that anybody has ever used {{artemis-jakarta-client}} _as
such_ to integrate ActiveMQ Artemis with a Jakarta EE container. Typically
folks would use the ActiveMQ Artemis JCA RA for that (which includes
{{artemis-jakarta-client}}) as it's the standard path for integration like
this. That said, there are containers that don't require a specific JCA RA for
messaging integration since not all JMS implementations provide a JCA RA.
bq. You presume it is possible, but how do you know? You must have tested it at
some point, right?
I've deployed the ActiveMQ Artemis JCA RA to various application servers in the
(long ago) past.
bq. I don't know why you see this as beyond the scope of Artemis'
documentation...
The EE space is big and even the messaging subset of the EE space is big. This
space is already covered by the relevant specifications, tutorials & docs from
Sun/Oracle, and docs from particular application servers. All this stuff is
beyond the scope of the ActiveMQ Artemis documentation just like all the
nuances of the JMS/Jakarta Messaging API are.
bq. ...it is definitely useful to know how to use the "artemis-jakarta-client"
package.
I think this may be where the real confusion is. As noted previously, the
_jakarta_ in {{artemis-jakarta-client}} does *not* equate to _EE_.
bq. Without even one usage example, it makes using the package very hard.
The {{artemis-jakarta-client}} can be used anywhere the {{artemis-jms-client}}
is used and we have [_lots_ of
examples|https://github.com/apache/activemq-artemis-examples] for that. We
don't have EE examples because that's beyond the scope of our documentation.
The EE docs from Oracle combined with those from your application server should
suffice for that. If they don't then I suggest you take that up with your
application server vendor/community.
bq. ...maybe is just the name of the package which is wrong...
I don't think the name of the package is wrong. The naming simply reflects the
namespace of the
[jira] [Comment Edited] (ARTEMIS-4716) Improve Jakarta Messaging / JMS documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838280#comment-17838280
]
Justin Bertram edited comment on ARTEMIS-4716 at 4/17/24 4:29 PM:
--
bq. There is no such thing as "Jakarta SE", only "Jakarta EE".
There may be no such thing as _Jakarta SE_ per se, but the most common
JMS/Jakarta Messaging use-case is in a Java SE context (i.e. not in an EE
container). This use-case involves basic clients sending an receiving messages
and includes frameworks like Spring. Clients still use Jakarta classes in this
Java SE context. The {{artemis-jakarta-client}} (which is based on the
{{artemis-jms-client}}) is provided to users for this purpose. The presence of
_jakarta_ in the name of the package does *not* equate to _EE_. Classes in the
{{jakarta}} namespace (and the {{javax}} namespace before it) have always been
viable in a Java SE context.
bq. Your package being named "jakarta" is where all my expectations come from...
I'm not 100% clear on what your expectations were, but as this conversation
continues it seems perhaps your expectations were misplaced.
bq. And a library author should value convenience, don't you think?
In general, I agree. Convenience should be valued. However, as with all things
it must be balanced with other priorities, some of which may actually compete
directly with convenience, but I digress.
bq. In any event, CDI or JNDI, I'm not picky, as long as there are clear
instructions stating the preferred way to use the library.
>From an implementer's perspective I'm not sure there is a clear preference.
>I'd say use whichever best fits your use-case.
bq. I don't think I can quite use WildFly as a template to integrate
"artemis-jakarta-client" in my application, can I?
You can't use it as a _template_ per se, but it's worth noting how WildFly
manages the integration. Most of the "hundreds and hundreds of lines" of code
you saw deals with configuring and managing the embedded broker. That's not
particularly relevant to your use-case. The main things it does to help EE
applications directly are (1) deploying the ActiveMQ Artemis JCA RA (which
enables MDB use-cases and provides connection pooling and XA support for any
messaging client running in the container) and (2) binding connection factories
into JNDI (which mainly enable connectivity from remote messaging clients).
There are some more nuances in there, but those are the main two things that
would impact someone in your situation. These are the kinds of things you'd
want to configure on _any_ application server with regards to messaging
integration.
bq. What I meant is, does any project using a Jakarta EE implementation (one
that doesn't already come with ActiveMQ, obviously) ever used
"artemis-jakarta-client" with dependency injection (or even at all)?
I can't say for sure that anybody has ever used {{artemis-jakarta-client}} _as
such_ to integrate ActiveMQ Artemis with a Jakarta EE container. Typically
folks would use the ActiveMQ Artemis JCA RA for that (which includes
{{artemis-jakarta-client}}) as it's the standard path for integration like
this. That said, there are containers that don't require a specific JCA RA for
messaging integration since not all JMS implementations provide a JCA RA.
bq. You presume it is possible, but how do you know? You must have tested it at
some point, right?
I've deployed the ActiveMQ Artemis JCA RA to various application servers in the
(long ago) past.
bq. I don't know why you see this as beyond the scope of Artemis'
documentation...
The EE space is big and even the messaging subset of the EE space is big. This
space is already covered by the relevant specifications, tutorials & docs from
Sun/Oracle, and docs from particular application servers. All this stuff is
beyond the scope of the ActiveMQ Artemis documentation just like all the
nuances of the JMS/Jakarta Messaging API are.
bq. ...it is definitely useful to know how to use the "artemis-jakarta-client"
package.
I think this may be where the real confusion is. As noted previously, the
_jakarta_ in {{artemis-jakarta-client}} does *not* equate to _EE_.
bq. Without even one usage example, it makes using the package very hard.
The {{artemis-jakarta-client}} can be used anywhere the {{artemis-jms-client}}
is used and we have [_lots_ of
examples|https://github.com/apache/activemq-artemis-examples] for that. We
don't have EE examples because that's beyond the scope of our documentation.
The EE docs from Oracle combined with those from your application server should
suffice for that. If they don't then I suggest you take that up with your
application server vendor/community.
bq. ...maybe is just the name of the package which is wrong...
I don't think the name of the package is wrong. The naming simply reflects the
namespace of the
[jira] [Commented] (ARTEMIS-4716) Improve Jakarta Messaging / JMS documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838280#comment-17838280
]
Justin Bertram commented on ARTEMIS-4716:
-
bq. There is no such thing as "Jakarta SE", only "Jakarta EE".
There may be no such thing as _Jakarta SE_ per se, but the most common
JMS/Jakarta Messaging use-case is in a Java SE context (i.e. not in an EE
container). This use-case involves basic clients sending an receiving messages
and includes frameworks like Spring. Clients still use Jakarta classes in this
Java SE context. The {{artemis-jakarta-client}} (which is based on the
{{artemis-jms-client}}) is provided to users for this purpose. The presence of
_jakarta_ in the name of the package does *not* equate to _EE_. Classes in the
{{jakarta}} namespace (and the {{javax}} namespace before it) have always been
viable in a Java SE context.
bq. Your package being named "jakarta" is where all my expectations come from...
I'm not 100% clear on what your expectations were, but as this conversation
continues it seems perhaps your expectations were misplaced.
bq. And a library author should value convenience, don't you think?
In general, I agree. Convenience should be valued. However, as with all things
it must the balanced with other priorities some of which may actually compete
directly with convenience, but I digress.
bq. In any event, CDI or JNDI, I'm not picky, as long as there are clear
instructions stating the preferred way to use the library.
>From an implementer's perspective I'm not sure there is a clear preference.
>I'd say use whichever best fits your use-case.
bq. I don't think I can quite use WildFly as a template to integrate
"artemis-jakarta-client" in my application, can I?
You can't use it as a _template_ per se, but it's worth noting how WildFly
manages the integration. Most of the "hundreds and hundreds of lines" of code
you saw deals with configuring and managing the embedded broker. That's not
particularly relevant to your use-case. The main things it does to help EE
applications directly are (1) deploying the ActiveMQ Artemis JCA RA (which
enables MDB use-cases and provides connection pooling and XA support for any
messaging client running in the container) and (2) binding connection factories
into JNDI (which mainly enable connectivity from remote messaging clients).
There are some more nuances in there, but those are the main two things that
would impact someone in your situation. These are the kinds of things you'd
want to configure on _any_ application server with regards to messaging
integration.
bq. What I meant is, does any project using a Jakarta EE implementation (one
that doesn't already come with ActiveMQ, obviously) ever used
"artemis-jakarta-client" with dependency injection (or even at all)?
I can't say for sure that anybody has ever used {{artemis-jakarta-client}} _as
such_ to integrate ActiveMQ Artemis with a Jakarta EE container. Typically
folks would use the ActiveMQ Artemis JCA RA for that (which includes
{{artemis-jakarta-client}}) as it's the standard path for integration like
this. That said, there are containers that don't require a specific JCA RA for
messaging integration since not all JMS implementations provide a JCA RA.
bq. You presume it is possible, but how do you know? You must have tested it at
some point, right?
I've deployed the ActiveMQ Artemis JCA RA to various application servers in the
(long ago) past.
bq. I don't know why you see this as beyond the scope of Artemis'
documentation...
The EE space is big and even the messaging subset of the EE space is big. This
space is already covered by the relevant specifications, tutorials & docs from
Sun/Oracle, and docs from particular application servers. All this stuff is
beyond the scope of the ActiveMQ Artemis documentation just like all the
nuances of the JMS/Jakarta Messaging API are.
bq. ...it is definitely useful to know how to use the "artemis-jakarta-client"
package.
I think this may be where the real confusion is. As noted previously, the
_jakarta_ in {{artemis-jakarta-client}} does *not* equate to _EE_.
bq. Without even one usage example, it makes using the package very hard.
The {{artemis-jakarta-client}} can be used anywhere the {{artemis-jms-client}}
is used and we have [_lots_ of
examples|https://github.com/apache/activemq-artemis-examples] for that. We
don't have EE examples because that's beyond the scope of our documentation.
The EE docs from Oracle combined with those from your application server should
suffice for that. If they don't then I suggest you take that up with your
application server vendor/community.
bq. ...maybe is just the name of the package which is wrong...
I don't think the name of the package is wrong. The naming simply reflects the
namespace of the implementation. Using _jakarta_ doesn't mean _EE_ now just
[jira] [Work logged] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?focusedWorklogId=915133=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915133 ] ASF GitHub Bot logged work on ARTEMIS-4723: --- Author: ASF GitHub Bot Created on: 17/Apr/24 14:46 Start Date: 17/Apr/24 14:46 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4880: URL: https://github.com/apache/activemq-artemis/pull/4880#issuecomment-2061437282 even thought I wanted to get rid of the shutdown.. that represented some semantic change.. and it's impossible to measure consequences. I will have to keep the behaviour to avoid breaking use cases and causing unexpected issues. Issue Time Tracking --- Worklog Id: (was: 915133) Time Spent: 50m (was: 40m) > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?focusedWorklogId=915120=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915120
]
ASF GitHub Bot logged work on AMQNET-727:
-
Author: ASF GitHub Bot
Created on: 17/Apr/24 13:26
Start Date: 17/Apr/24 13:26
Worklog Time Spent: 10m
Work Description: AndyDeMauriceGEDigital commented on PR #37:
URL:
https://github.com/apache/activemq-nms-openwire/pull/37#issuecomment-2061260927
@Havret Can you please review this change?
Issue Time Tracking
---
Worklog Id: (was: 915120)
Time Spent: 50m (was: 40m)
> Thread sync error with MessageConsumer.pendingAck
> -
>
> Key: AMQNET-727
> URL: https://issues.apache.org/jira/browse/AMQNET-727
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 1.8.0
>Reporter: Andy DeMaurice
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> pendingAck is accessed by multiple threads; in most places where it is
> written, it is done along with accessing *deliveredMessages*, so it is
> written within a *lock(this.deliveredMessages)* block.
> However, this call stack shows where pendingAck gets assigned to a new
> MessageAck object, NOT within the lock... and it is subject to being
> overwritten by another thread (usually the other thread is in
> MessageConsumer.Acknowledge() :
>
> Apache.NMS.ActiveMQ.MessageConsumer.AckLater(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Apache.NMS.ActiveMQ.AckType)
> Apache.NMS.ActiveMQ.MessageConsumer.AfterMessageIsConsumed(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Boolean)
> Apache.NMS.ActiveMQ.MessageConsumer.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Iterate()
> Apache.NMS.ActiveMQ.Threads.DedicatedTaskRunner.Run()
>
> The usual symptom I see is a NullReferenceException in this section of code
> within AckLater; because pendingAck has been set to null by another thread:
>
> if(oldPendingAck == null)
> {
> pendingAck.FirstMessageId = pendingAck.LastMessageId;
> }
> else if(oldPendingAck.AckType == pendingAck.AckType)
> {
> pendingAck.FirstMessageId = oldPendingAck.FirstMessageId;
> }
--
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=915115=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915115 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 17/Apr/24 13:04 Start Date: 17/Apr/24 13:04 Worklog Time Spent: 10m Work Description: gemmellr commented on code in PR #3: URL: https://github.com/apache/activemq-artemis-console-plugin/pull/3#discussion_r1568739101 ## artemis-console-distribution/src/main/assembly/source-assembly.xml: ## @@ -0,0 +1,137 @@ + + +http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2; +xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd;> + + source-release + + + zip + tar.gz + + + true + + + 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: 2h 40m > 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] (ARTEMIS-4723) org.apache.activemq.artemis.utils.actors.Handler$Counter left on the ThreadLocal
[ https://issues.apache.org/jira/browse/ARTEMIS-4723?focusedWorklogId=915087=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915087 ] ASF GitHub Bot logged work on ARTEMIS-4723: --- Author: ASF GitHub Bot Created on: 17/Apr/24 11:18 Start Date: 17/Apr/24 11:18 Worklog Time Spent: 10m Work Description: cardamon commented on PR #4880: URL: https://github.com/apache/activemq-artemis/pull/4880#issuecomment-2061025234 > @cardamon notice I'm keeping you as the author on the commit. as you discovered the issue. > > I went further and just removed the usage. if all my tests are good I will merge this. Thanks! Issue Time Tracking --- Worklog Id: (was: 915087) Time Spent: 40m (was: 0.5h) > org.apache.activemq.artemis.utils.actors.Handler$Counter left on the > ThreadLocal > > > Key: ARTEMIS-4723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4723 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > org.apache.activemq.artemis.utils.actors.Handler$Counter is left on the > ThreadLocal. > This is used to verify if the execution is InHander. > The object could be removed after done. So it's not a growing leak (meaning > it will keep growing), but it's an unnecessary allocation that can be avoided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4719) Artemis Metrics plugin reports wrong data
[ https://issues.apache.org/jira/browse/ARTEMIS-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838023#comment-17838023 ] Mohanavalli A commented on ARTEMIS-4719: We have a custom metrics plugin implementing ActiveMQMetricsPlugin. This plugin only reads the `artemis.message.count` metric, renames to `eesb.message.count` and add a few tags for monitoring purpose. There is no aggregation and its single value per address. There is no way to reproduce this as of now. > Artemis Metrics plugin reports wrong data > - > > Key: ARTEMIS-4719 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4719 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Mohanavalli A >Priority: Minor > Attachments: 6m peak.png, image-2024-04-10-12-46-10-394.png > > > We are using an Artemis broker metrics plugin to monitor the message count on > each address of the broker. Recently we have noticed that the plugin reported > values which were not realistic and not matching with any of our other > monitoring information available. > !6m peak.png|width=502,height=471! > For a particular address, the plugin reported below values every minute. The > messages count increase from 437k to 5million and 451K to 6million and a fall > from 6M to 462 K are not realistic considering the producer/consumers > capacity. From the values 5M and 6M look to be fake values. > !image-2024-04-10-12-46-10-394.png|width=211,height=429! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4716) Improve Jakarta Messaging / JMS documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838011#comment-17838011
]
Daniel Martin edited comment on ARTEMIS-4716 at 4/17/24 7:38 AM:
-
{quote}integrating 3rd party implementations (...) [is] fairly common with
messaging. It's quite common to integrate a 3rd party JMS implementation with
an EE application server
{quote}
If so, then surely it must be easy to get hold of some real-world examples of
people having integrated it.
{quote}To be clear, there is nothing EE-specific about the
{{artemis-jakarta-client}} package. In fact, I would say its main use-case is
in a Java SE context.
{quote}
This is extremely confusing. There is no such thing as "Jakarta SE", only
"Jakarta EE". Your package being named "jakarta" is where all my expectations
come from...
{quote}Using Jakarta classes really has nothing to do with CDI. Those two
things are mutually exclusive. Furthermore, I'm not sure if using CDI vs.
manual JNDI lookups is more robust or necessarily recommended more highly. I
see CDI mainly as a convenience for developers and not much more. I don't do a
lot of EE programming these days so maybe there's more to it that I'm not
familiar with.
{quote}
CDI is definitely more prevalent than JNDI in my experience. And a library
author should value convenience, don't you think? In any event, CDI or JNDI,
I'm not picky, as long as there are clear instructions stating the preferred
way to use the library. What I'm truly after is avoiding manual resource
management, which is one of the benefits of dependency injection. But
integrating with Jakarta definitely goes beyond implementing Jakarta
interfaces, in my opinion.
{quote}ActiveMQ Artemis is the JMS implementation shipped with
[WildFly|https://www.wildfly.org/].
{quote}
This is not quite what I meant. I don't think I can quite use WildFly as a
template to integrate "artemis-jakarta-client" in my application, can I? I see
hundreds and hundreds of lines related to ActiveMQ in it, but I wouldn't expect
to have to do the same. What I meant is, does any project _using_ a Jakarta EE
implementation (one that doesn't already come with ActiveMQ, obviously) ever
used "artemis-jakarta-client" with dependency injection (or even at all)?
{quote}If all you're doing is injecting an ActiveMQ Artemis
{{ConnectionFactory}} then you'll need to inform the application server about
how to actually instantiate that object. (...) This is beyond the scope of the
ActiveMQ Artemis documentation.
{quote}
I understand this, now I need to know how, which is why I'm looking for an
example of somebody having done it before, if this ever happened. You presume
it is possible, but how do you know? You must have tested it at some point,
right? I don't know why you see this as beyond the scope of Artemis'
documentation, it is definitely useful to know how to use the
"artemis-jakarta-client" package. Without even one usage example, it makes
using the package very hard. But then again, maybe is just the name of the
package which is wrong, and none of my expectations hold because it isn't
really meant to be an integration of Artemis with Jakarta (EE).
was (Author: JIRAUSER290941):
{quote}integrating 3rd party implementations (...) [is] fairly common with
messaging. It's quite common to integrate a 3rd party JMS implementation with
an EE application server
{quote}
If so, then surely it must be easy to get hold of some real-world examples of
people having integrated it.
{quote}To be clear, there is nothing EE-specific about the
{{artemis-jakarta-client}} package. In fact, I would say its main use-case is
in a Java SE context.
{quote}
This is extremely confusing. There is no such thing as "Jakarta SE", only
"Jakarta EE". You package being named "jakarta" is where all my expectations
come from...
{quote}Using Jakarta classes really has nothing to do with CDI. Those two
things are mutually exclusive. Furthermore, I'm not sure if using CDI vs.
manual JNDI lookups is more robust or necessarily recommended more highly. I
see CDI mainly as a convenience for developers and not much more. I don't do a
lot of EE programming these days so maybe there's more to it that I'm not
familiar with.
{quote}
CDI is definitely more prevalent than JNDI in my experience. And a library
author should value convenience, don't you think? In any event, CDI or JNDI,
I'm not picky, as long as there are clear instructions stating the preferred
way to use the library. What I'm truly after is avoiding manual resource
management, which is one of the benefits of dependency injection. But
integrating with Jakarta definitely goes beyond implementing Jakarta
interfaces, in my opinion.
{quote}ActiveMQ Artemis is the JMS implementation shipped with
[WildFly|https://www.wildfly.org/].
{quote}
This is not quite what I meant. I don't think I
[jira] [Commented] (ARTEMIS-4716) Improve Jakarta Messaging / JMS documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838011#comment-17838011
]
Daniel Martin commented on ARTEMIS-4716:
{quote}integrating 3rd party implementations (...) [is] fairly common with
messaging. It's quite common to integrate a 3rd party JMS implementation with
an EE application server
{quote}
If so, then surely it must be easy to get hold of some real-world examples of
people having integrated it.
{quote}To be clear, there is nothing EE-specific about the
{{artemis-jakarta-client}} package. In fact, I would say its main use-case is
in a Java SE context.
{quote}
This is extremely confusing. There is no such thing as "Jakarta SE", only
"Jakarta EE". You package being named "jakarta" is where all my expectations
come from...
{quote}Using Jakarta classes really has nothing to do with CDI. Those two
things are mutually exclusive. Furthermore, I'm not sure if using CDI vs.
manual JNDI lookups is more robust or necessarily recommended more highly. I
see CDI mainly as a convenience for developers and not much more. I don't do a
lot of EE programming these days so maybe there's more to it that I'm not
familiar with.
{quote}
CDI is definitely more prevalent than JNDI in my experience. And a library
author should value convenience, don't you think? In any event, CDI or JNDI,
I'm not picky, as long as there are clear instructions stating the preferred
way to use the library. What I'm truly after is avoiding manual resource
management, which is one of the benefits of dependency injection. But
integrating with Jakarta definitely goes beyond implementing Jakarta
interfaces, in my opinion.
{quote}ActiveMQ Artemis is the JMS implementation shipped with
[WildFly|https://www.wildfly.org/].
{quote}
This is not quite what I meant. I don't think I can quite use WildFly as a
template to integrate "artemis-jakarta-client" in my application, can I? I see
hundreds and hundreds of lines related to ActiveMQ in it, but I wouldn't expect
to have to do the same. What I meant is, does any project _using_ a Jakarta EE
implementation (one that doesn't already come with ActiveMQ, obviously) ever
used "artemis-jakarta-client" with dependency injection (or even at all)?
{quote}If all you're doing is injecting an ActiveMQ Artemis
{{ConnectionFactory}} then you'll need to inform the application server about
how to actually instantiate that object. (...) This is beyond the scope of the
ActiveMQ Artemis documentation.
{quote}
I understand this, now I need to know how, which is why I'm looking for an
example of somebody having done it before, if this ever happened. You presume
it is possible, but how do you know? You must have tested it at some point,
right? I don't know why you see this as beyond the scope of Artemis'
documentation, it is definitely useful to know how to use the
"artemis-jakarta-client" package. Without even one usage example, it makes
using the package very hard. But then again, maybe is just the name of the
package which is wrong, and none of my expectations hold because it isn't
really meant to be an integration of Artemis with Jakarta (EE).
> Improve Jakarta Messaging / JMS documentation
> -
>
> Key: ARTEMIS-4716
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4716
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JMS
>Affects Versions: 2.33.0
>Reporter: Daniel Martin
>Priority: Minor
>
> I'm struggling to understand [these
> instructions|https://activemq.apache.org/components/artemis/documentation/latest/using-jms.html]
> to use Artemis in the context of Jakarta Messaging which perhaps could be
> updated / simplified / improved.
> At the moment, I'm depending on {{artemis-jakarta-client}} and manually
> instantiating {{ActiveMQConnectionFactory}}. While investigating a memory
> leak that may come from my usage of ActiveMQ, I wanted to simplify this part
> and rely on dependency injection instead. However, I don't begin to
> understand how to do such thing.
> My expectation was to be able to use the {{@Inject}} annotation to get a
> reference to a {{ConnectionFactory}}, {{JMSContext}}, or similar and to be
> able to provide configuration such as broker address and credentials
> _somewhere_ as to end up with a reference to a {{Connection}} which is
> ultimately what I need. Is this possible? What's the recommended way? Is
> there any (working) reference examples?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4729) Upgrade slf4j version to 2.0.12
[ https://issues.apache.org/jira/browse/ARTEMIS-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino resolved ARTEMIS-4729. -- Fix Version/s: 2.34.0 Resolution: Fixed > Upgrade slf4j version to 2.0.12 > --- > > Key: ARTEMIS-4729 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4729 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >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] [Commented] (ARTEMIS-4729) Upgrade slf4j version to 2.0.12
[ https://issues.apache.org/jira/browse/ARTEMIS-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838001#comment-17838001 ] ASF subversion and git services commented on ARTEMIS-4729: -- Commit f4581deb9dfa665b8a28c3f027ff7c71defca630 in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f4581deb9d ] ARTEMIS-4729 Upgrade slf4j version to 2.0.12 > Upgrade slf4j version to 2.0.12 > --- > > Key: ARTEMIS-4729 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4729 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4728) Upgrade jgroups version to 5.3.4.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838000#comment-17838000 ] ASF subversion and git services commented on ARTEMIS-4728: -- Commit e065b4448fd03d573b34973044ba654b9212246b in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e065b4448f ] ARTEMIS-4728 Upgrade jgroups version to 5.3.4.Final > Upgrade jgroups version to 5.3.4.Final > -- > > Key: ARTEMIS-4728 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4728 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4728) Upgrade jgroups version to 5.3.4.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4728?focusedWorklogId=915057=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915057 ] ASF GitHub Bot logged work on ARTEMIS-4728: --- Author: ASF GitHub Bot Created on: 17/Apr/24 07:11 Start Date: 17/Apr/24 07:11 Worklog Time Spent: 10m Work Description: brusdev merged PR #4890: URL: https://github.com/apache/activemq-artemis/pull/4890 Issue Time Tracking --- Worklog Id: (was: 915057) Time Spent: 20m (was: 10m) > Upgrade jgroups version to 5.3.4.Final > -- > > Key: ARTEMIS-4728 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4728 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4729) Upgrade slf4j version to 2.0.12
[ https://issues.apache.org/jira/browse/ARTEMIS-4729?focusedWorklogId=915058=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-915058 ] ASF GitHub Bot logged work on ARTEMIS-4729: --- Author: ASF GitHub Bot Created on: 17/Apr/24 07:12 Start Date: 17/Apr/24 07:12 Worklog Time Spent: 10m Work Description: brusdev merged PR #4891: URL: https://github.com/apache/activemq-artemis/pull/4891 Issue Time Tracking --- Worklog Id: (was: 915058) Time Spent: 20m (was: 10m) > Upgrade slf4j version to 2.0.12 > --- > > Key: ARTEMIS-4729 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4729 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4728) Upgrade jgroups version to 5.3.4.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino resolved ARTEMIS-4728. -- Fix Version/s: 2.34.0 Resolution: Fixed > Upgrade jgroups version to 5.3.4.Final > -- > > Key: ARTEMIS-4728 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4728 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
