Re: OPENWIRE acceptor parameter not being used

[Robbie Gemmell]

>From the documentation you linked:

"Note at the beginning the InactivityMonitor negotiates the
appropriate maxInactivityDuration and
maxInactivityDurationInitalDelay. The shortest duration is taken for
the connection."

So I'd guess the client is asking for 30sec+10sec given those are the
defaults, and so that is what is used.


On Fri, 20 May 2022 at 18:52, Steigerwald, Aaron
 wrote:
>
> Hello,
>
> I'm trying to set the maxInactivityDuration parameter on an Artemis 2.21.0 
> OPENWIRE acceptor. I think I followed the directions correctly from 
> https://activemq.apache.org/components/artemis/documentation/latest/openwire.html.
>  Here's what the acceptor looks like:
>
> tcp://0.0.0.0:${artemis.port.broker}?protocols=OPENWIRE;sslEnabled=true;keyStorePath=${artemis.broker.keyStore.uri};keyStorePassword=${artemis.broker.keyStor
> ePassword};trustStorePath=${artemis.broker.trustStore.uri};trustStorePassword=${artemis.broker.trustStorePassword};enabledProtocols=TLSv1.2;needClientAuth=true;supportAdvisory=false;suppressInter
> nalManagementObjects=true;maxInactivityDuration=6
>
> However, my ActiveMQ client logs the following value received from the broker:
>
> 20 May 2022 13:41:53.319 DEBUG [ActiveMQ Transport: 
> ssl://localhost/127.0.0.1:61629] - Received WireFormat: WireFormatInfo { 
> version=12, properties={TcpNoDelayEnabled=true, SizePrefixDisabled=false, 
> CacheSize=1024, ProviderName=ActiveMQ, StackTraceEnabled=true, 
> PlatformDetails=Java, CacheEnabled=false, TightEncodingEnabled=true, 
> MaxFrameSize=9223372036854775807, MaxInactivityDuration=3, 
> MaxInactivityDurationInitalDelay=1, ProviderVersion=5.16.0}, 
> magic=[A,c,t,i,v,e,M,Q]}
>
> Also, my ActiveMQ client disconnects after 40 seconds (MaxInactivityDuration 
> + MaxInactivityDurationInitalDelay) when using useKeepAlive=false.
>
> What am I doing wrong? How can I get the Artemis OPENWIRE acceptor to 
> recognize and use the maxInactivityDuration parameter?
>
> Thank you,
> Aaron Steigerwald

Re: [External] - Re: How to avoid AMQ229014 TTL "dump" for a "patient" Python 3 Stomp Listener

[Robbie Gemmell]

Both your 'as is' code and 'on the other hand' description have
from_server_hb_millis = 1 so its not clear what the other one was
meant to be. Since you later referenced 'not requesting server HBs'
I'd maybe guess your working case was just leaving it at the default
value of 0. Presumably setting it to a higher value, larger than your
expected message processing time, would also be workable.

On Fri, 24 Jun 2022 at 14:30, Richard Bergmann
 wrote:
>
> Sorry, I hope I am not beating a dead horse here, but I thought it might be 
> helpful to report the results of my investigation.
>
> First of all, recall that my use case is the listener could be patient for 
> long periods of time but then become busy on a long-running task as the 
> result of a message received -- much longer than TTL in both cases.
>
> Now consider this code, which I used in my investigation:
>
> ---
> # Message Consumer/Worker that monitors the "AAA" queue.
> from json import dumps
> import loggers
> from stomp import (Connection12,
>ConnectionListener)
> import sys
> import time
>
>
> logger = loggers.newlogger(__name__)
>
>
> # Listener that consumes messages requesting AAA processing.
> class AAAHeartbeatListener(ConnectionListener):
> def __init__(self,
>  conn):
> self.conn = conn
>
> def on_connected(self,
>  frame):
> # Called by the STOMP connection when a CONNECTED frame is received 
> (after a connection has been established or re-established).
> # Parameters: frame (Frame) - the stomp frame
> logger.info("on_connected: " + str(frame))
>
> def on_connecting(self,
>   host_and_port):
> # Called by the STOMP connection once a TCP/IP connection to the 
> STOMP server has been established or re-established. Note that at this point, 
> no connection has been established on the STOMP protocol level. For this, you 
> need to invoke the “connect" method on the connection.
> # Parameters: host_and_port ((str,int)) - a tuple containing the host 
> name and port number to which the connection has been established.
> logger.info("on_connecting: " + str(host_and_port))
>
> def on_disconnected(self):
> # Called by the STOMP connection when a TCP/IP connection to the 
> STOMP server has been lost. No messages should be sent via the connection 
> until it has been reestablished.
> logger.info("on_disconnected")
>
> def on_disconnecting(self):
> # Called before a DISCONNECT frame is sent.
> logger.info("on_disconnecting")
>
> def on_error(self,
>  frame):
> # Called by the STOMP connection when an ERROR frame is received.
> # Parameters: frame (Frame) - the stomp frame
> logger.error("on_error: " + str(frame))
>
> def on_heartbeat(self):
> # Called on receipt of a heartbeat.
> logger.info("on_heartbeat")
>
> def on_heartbeat_timeout(self):
> # Called by the STOMP connection when a heartbeat message has not 
> been received beyond the specified period.
> logger.info("on_heartbeat_timeout")
>
> def on_message(self,
>frame):
> # Called by the STOMP connection when a MESSAGE frame is received.
> # Parameters: frame (Frame) - the stomp frame
> # message is a stomp.utils.Frame with:
> # message.cmd == "MESSAGE"
> # message.headers == dict()
> # message.body == str
> logger.debug("on_message: " + str(frame))
>
> try:
> message_id = frame.headers["message-id"]
> subscription = int(frame.headers["subscription"])
>
> logger.info("Processing message with ID:" + str(message_id) + " 
> and Subscription:" + str(subscription))
> # Simulate a long-running process -- much longer than TTL.
> for _ in range(0, 1200):
> # 100ms sleep intervals (should) keep the client from 
> blocking.
> time.sleep(0.1)
> logger.info("Processed message with ID:" + str(message_id) + " 
> and Subscription:" + str(subscription))
> self.conn.ack(message_id,
>   subscription)
> logger.info("Message ACKed")
> except:
> logger.error(loggers.format_exc_info("Failed to process message: 
> " + str(frame)))
> self.conn.nack(message_id,
>subscription)
> logger.info("Message NACKed")
>
> def on_receipt(self,
>frame):
> # Called by the STOMP connection when a RECEIPT frame is received, 
> sent by the server if requested by the client using the ‘receipt’ header.
> # Parameters: frame (Frame) - the stomp frame
> logger.debug("on_receipt: " + str(frame))
>
> def on_receiver_loop_completed(self,
>frame):
> # Called w

Re: [External] - Re: How to avoid AMQ229014 TTL "dump" for a "patient" Python 3 Stomp Listener

[Robbie Gemmell]

Whether it is expected or not may depend more on the client side impl
at this point; your wondering if it may be using the same thread for
processing the message / listener as it does the heartbeats (and thus
isnt processing any while your slow listener blocks it) seems a fairly
reasonable explanation, but isnt something we can really say one way
or the other, but perhaps the library authors can.

Its either that or the server isnt sending the requested heartbeats. I
know nothing about the stomp impl but I'd guess theres some debug that
could be enabled to see what looks to be happening, especially as in
this case the point is there is no normal traffic so it should stand
out.

On Fri, 24 Jun 2022 at 16:30, Richard Bergmann
 wrote:
>
> I'm sorry, that was a typo.  It should have read from_server_hb_millis = 0, 
> which is the way I ran it, and the way I plan to run it in the future.
>
> I have very little control over how long it will take to process a message -- 
> sometimes it can take hours.
>
> I just wanted to confirm that this was expected behaviour and to give anyone 
> else with a similar use case a head up.
>
> At the end of the day, and after two weeks of work, I finally have a working 
> solution, i.e., I have successfully migrated from Classic to Artemis.
>
> And all of this just so I can leverage more granular priorites!
>
> 
> From: Robbie Gemmell 
> Sent: Friday, June 24, 2022 10:50 AM
> To: users@activemq.apache.org 
> Subject: Re: [External] - Re: How to avoid AMQ229014 TTL "dump" for a 
> "patient" Python 3 Stomp Listener
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Both your 'as is' code and 'on the other hand' description have
> from_server_hb_millis = 1 so its not clear what the other one was
> meant to be. Since you later referenced 'not requesting server HBs'
> I'd maybe guess your working case was just leaving it at the default
> value of 0. Presumably setting it to a higher value, larger than your
> expected message processing time, would also be workable.
>
> On Fri, 24 Jun 2022 at 14:30, Richard Bergmann
>  wrote:
> >
> > Sorry, I hope I am not beating a dead horse here, but I thought it might be 
> > helpful to report the results of my investigation.
> >
> > First of all, recall that my use case is the listener could be patient for 
> > long periods of time but then become busy on a long-running task as the 
> > result of a message received -- much longer than TTL in both cases.
> >
> > Now consider this code, which I used in my investigation:
> >
> > ---
> > # Message Consumer/Worker that monitors the "AAA" queue.
> > from json import dumps
> > import loggers
> > from stomp import (Connection12,
> >ConnectionListener)
> > import sys
> > import time
> >
> >
> > logger = loggers.newlogger(__name__)
> >
> >
> > # Listener that consumes messages requesting AAA processing.
> > class AAAHeartbeatListener(ConnectionListener):
> > def __init__(self,
> >  conn):
> > self.conn = conn
> >
> > def on_connected(self,
> >  frame):
> > # Called by the STOMP connection when a CONNECTED frame is received 
> > (after a connection has been established or re-established).
> > # Parameters: frame (Frame) - the stomp frame
> > logger.info("on_connected: " + str(frame))
> >
> > def on_connecting(self,
> >   host_and_port):
> > # Called by the STOMP connection once a TCP/IP connection to the 
> > STOMP server has been established or re-established. Note that at this 
> > point, no connection has been established on the STOMP protocol level. For 
> > this, you need to invoke the “connect" method on the connection.
> > # Parameters: host_and_port ((str,int)) - a tuple containing the 
> > host name and port number to which the connection has been established.
> > logger.info("on_connecting: " + str(host_and_port))
> >
> > def on_disconnected(self):
> > # Called by the STOMP connection when a TCP/IP connection to the 
> > STOMP server has been lost. No messages should be sent via the connection 
> > until it has been reestablished.
> > logger.info("on_disconnected")
> >
> > def on_disconnecting(self):
> > # Called befo

Re: [External] - Re: JSON Message Body Not Display in Artemis Web Console

[Robbie Gemmell]

On Mon, 27 Jun 2022 at 16:07, Richard Bergmann
 wrote:
>
> Here:
>
> -
> from json import dumps
> import stomp
> import sys
>
>
> conn = stomp.Connection12(heartbeats=(3,0))
> conn.connect("admin",
>  "admin",
>  wait=True,
>  headers = {"client-id": sys.argv[0]})
>
>
> message = {"item": """This is a lot of text.
> In fact, it's an incredible amount of text.
> It's enough text so as to get the size of the message to 1867 bytes.
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, 
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo 
> consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse 
> cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non 
> proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, 
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo 
> consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse 
> cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non 
> proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, 
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo 
> consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse 
> cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non 
> proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, 
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo 
> consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse 
> cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non 
> proident, sunt in culpa qui officia deserunt mollit anim id est laborum."""}
>
>
> conn.send("Some Queue",
>   dumps(message),
>   "application/json",
>   headers={"destination-type": "ANYCAST",
>"persistent": "true",
>"priority": 0})
>
> conn.disconnect()
> -
>
> Did the screenshot come through from my first post?  If I try to "Show" the 
> message it shows the message ID and an empty box underneath "Displaying body 
> as bytes (turned off)"
>

Domenico seems to have answered, but to this bit...no, the mailing
lists are text based and strip essentially all attachments, so your
screenshot didnt make it.

> 
> From: Domenico Francesco Bruscino 
> Sent: Monday, June 27, 2022 10:48 AM
> To: users@activemq.apache.org 
> Subject: [External] - Re: JSON Message Body Not Display in Artemis Web Console
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Hi Rich,
>
> how are you sending your JSON message, can you share a simple reproducer?
>
> Regards,
> Domenico
>
> On Mon, 27 Jun 2022 at 14:46, Richard Bergmann 
> wrote:
>
> > I have a queue with a 1867 byte JSON message, but the message body is not
> > displayed when I "Show" message.  Not sure what "Displaying body as byes
> > (turned off)" means.  I would find nothing in the documentation or config
> > files and I come up short on Google searches as well.
> >
> > Can anyone provide me with any insight?
> >
> > Thank you!
> >
> > Regards,
> >
> > Rich Bergmann
> >
> >
> > --
> > The information contained in this e-mail and any attachments from COLSA
> > Corporation may contain company sensitive and/or proprietary information,
> > and is intended only for the named recipient to whom it was originally
> > addressed. If you are not the intended recipient, any disclosure,
> > distribution, or copying of this e-mail or its attachments is strictly
> > prohibited. If you have received this e-mail in error, please notify the
> > sender immediately by return e-mail and permanently delete the e-mail and
> > any attachments.
> >
> > COLSA Proprietary
> >
> 
> The information contained in this e-mail and any attachments from COLSA 
> Corporation may contain company sensitive and/or proprietary information, and 
> is intended only for the named recipient to whom it was originally addressed. 
> If you are not the intended recipient, any disclosure, distribution, or 
> copying of this e-mail or its attachments is strictly prohibited. If you have 
> received this e-mail in error, p

Re: JSON Message Body Not Display in Artemis Web Console

[Robbie Gemmell]

There was a followup mail, but it started a new thread due to the mail
server/client screwing with the initial response.

See the continuation at
https://lists.apache.org/thread/zs57b4yqyhwvdl1fg9m2s4mbzw511r2x

On Wed, 20 Jul 2022 at 23:24, Justin Bertram  wrote:
>
> Any feedback here on Domenico's request for a way to reproduce the problem?
>
>
> Justin
>
> On Mon, Jun 27, 2022 at 7:46 AM Richard Bergmann
>  wrote:
>
> > I have a queue with a 1867 byte JSON message, but the message body is not
> > displayed when I "Show" message.  Not sure what "Displaying body as byes
> > (turned off)" means.  I would find nothing in the documentation or config
> > files and I come up short on Google searches as well.
> >
> > Can anyone provide me with any insight?
> >
> > Thank you!
> >
> > Regards,
> >
> > Rich Bergmann
> >
> >
> > --
> > The information contained in this e-mail and any attachments from COLSA
> > Corporation may contain company sensitive and/or proprietary information,
> > and is intended only for the named recipient to whom it was originally
> > addressed. If you are not the intended recipient, any disclosure,
> > distribution, or copying of this e-mail or its attachments is strictly
> > prohibited. If you have received this e-mail in error, please notify the
> > sender immediately by return e-mail and permanently delete the e-mail and
> > any attachments.
> >
> > COLSA Proprietary
> >

Re: Artemis - Large Message - Core => AMQP

[Robbie Gemmell]

The mailing lists strip basically all attachments so noone saw what
you sent. You could attach it to the JIRA where the original was.

On Fri, 22 Jul 2022 at 11:22, Andy Yar  wrote:
>
> Hello,
> Using the LargeServerMessageImpl was just an attempt providing a seemingly 
> easy way to introduce a kind of Large Message into the test. I'm not familiar 
> with the code base at all - so I simply tried to somehow provide the 
> requested test replicating my "sending via Core -> receiving via Qpid" issue. 
> The same applies to the explicit AMQP conversion - the encountered error 
> simply pointed on it. Is there an intended "test way" to model the message 
> transfer among different clients/protocols?
>
> Anyway, I've changed the test to employ 
> ClientLargeMessageImpl/ClientMessageImpl instead of the server-related 
> LargeServerMessageImpl with a very similar result. Does that implementation 
> fit the simulated use case (sending via Core -> receiving via Qpid AMQP) 
> better or is the explicit AMQP conversion misused?
>
> Please, see the attached patch.
>
> On Mon, Jul 18, 2022 at 3:50 PM Clebert Suconic  
> wrote:
>>
>> AMQP to Core and Core to AMQP conversions expect you using JMS clients
>> to generate your message. There are certain caveats that both clients
>> will add to the messages.
>>
>>
>> Usually I have seen more users doing weird conversions in AMQP when
>> they use a C++ or non Java Client.. but on your case you used a Core
>> Client, using a non standard way to send a message (ServerMessage from
>> the client)... and it's not clear the message is correctly set for a
>> conversion to work.
>>
>>
>> I need you to provide some explanation on what you're doing.. if this
>> was  a way to hack a bug your saw or if this is just the way you're
>> using it.
>>
>>
>> if this is how you're actually using, I would suggest you either use
>> the proper APIs or if you're doing some hack for performance
>> consideration you have to set the message in a better way the
>> converters would understand...
>>
>> On Mon, Jul 18, 2022 at 9:38 AM Clebert Suconic
>>  wrote:
>> >
>> > Are you using the LargeServerMessageImpl on your client, or that was
>> > just a "hack" to reproduce your issue.
>> >
>> >
>> > LargeServerMessageImpl was not meant to be used on the client. But if
>> > you're doing that just to show something you faced in production it's
>> > ok.. but using the LargeServerMessageImpl to send a Client Message is
>> > a big not for me.
>> >
>> > The only reason we do that is for server to server transfer.
>> >
>> > On Mon, Jul 18, 2022 at 7:39 AM Andy Yar  wrote:
>> > >
>> > > Hello,
>> > > Yes, the 2.23.1 test instance was freshly created.
>> > >
>> > > I've attached a test as a part of ARTEMIS-3897
>> > > . I hope it helps.
>> > >
>> > >
>> > > On Sat, Jul 16, 2022 at 5:21 PM Clebert Suconic 
>> > > 
>> > > wrote:
>> > >
>> > > > Did you start with fresh data on 2.23.1.
>> > > >
>> > > > If you did please provide a self enclosing test reproducing your issue.
>> > > >
>> > > > On Fri, Jul 15, 2022 at 4:29 AM Andy Yar  wrote:
>> > > >
>> > > > > A quick test using 2.23.1 results in the same error payload being
>> > > > received:
>> > > > >
>> > > > > "Message(address='test', durable=True, priority=4,
>> > > > > annotations=AnnotationDict({symbol('x-opt-jms-dest'): byte(0),
>> > > > > symbol('x-opt-jms-msg-type'): byte(0)}),
>> > > > > properties={'JMSXDeliveryCount': None, '_AMQ_LARGE_SIZE': 67},
>> > > > > body='Conversion to AMQP error: Error reading in simpleString,
>> > > > > length=1330464032 is greater than readableBytes=62')"
>> > > > >
>> > > > > Best regards
>> > > > >
>> > > > > On Thu, Jul 14, 2022 at 9:18 PM Clebert Suconic
>> > > > >  wrote:
>> > > > > >
>> > > > > > There's been a few fixes in AMQP Large message.
>> > > > > >
>> > > > > >
>> > > > > > More prominently a fix with the JDBC implementation between 2.17 
>> > > > > > and
>> > > > > HEAD.
>> > > > > >
>> > > > > >
>> > > > > > I would definitely recommend you to upgrade.
>> > > > > >
>> > > > > > On Thu, Jul 14, 2022 at 10:26 AM Justin Bertram 
>> > > > > > 
>> > > > > wrote:
>> > > > > > >
>> > > > > > > I would expect this to work. Can you try this on the latest 
>> > > > > > > release
>> > > > > (i.e.
>> > > > > > > 2.23.1) [1]?
>> > > > > > >
>> > > > > > > If it still doesn't work please open a Jira with all the details
>> > > > > necessary
>> > > > > > > to reproduce the problem. An actual test-case would be ideal.
>> > > > > > >
>> > > > > > > Thanks!
>> > > > > > >
>> > > > > > >
>> > > > > > > Justin
>> > > > > > >
>> > > > > > > [1] https://activemq.apache.org/components/artemis/download/
>> > > > > > >
>> > > > > > > On Thu, Jul 14, 2022 at 9:20 AM Andy Yar 
>> > > > wrote:
>> > > > > > >
>> > > > > > > > Hello,
>> > > > > > > > Sending a message as a Large Message via Core protocol and
>> > > > receiving
>> > > > > > > > it via AMQP on Artemis 2.17.0 ends with receiving 

Re: Artemis - Large Message - Core => AMQP

[Robbie Gemmell]

The snagging described seems to be in the Core sending+conversion legs
of things, so the receiving AMQP client wouldnt seem likely to make
much difference currently. Once its converted any AMQP 1.0 client
should be able to receive it really.

On Fri, 22 Jul 2022 at 20:01, Clebert Suconic  wrote:
>
> If you’re not using qpid JMS it will not work.
>
> On Fri, Jul 22, 2022 at 8:06 AM Andy Yar  wrote:
>
> > There is another attempt employing AMQP test structures. It produces the
> > same incorrect message body.
> >
> > On Fri, Jul 22, 2022 at 12:21 PM Andy Yar  wrote:
> >
> >> Hello,
> >> Using the LargeServerMessageImpl was just an attempt providing a
> >> seemingly easy way to introduce a kind of Large Message into the test. I'm
> >> not familiar with the code base at all - so I simply tried to somehow
> >> provide the requested test replicating my "sending via Core -> receiving
> >> via Qpid" issue. The same applies to the explicit AMQP conversion - the
> >> encountered error simply pointed on it. Is there an intended "test way" to
> >> model the message transfer among different clients/protocols?
> >>
> >> Anyway, I've changed the test to employ
> >> ClientLargeMessageImpl/ClientMessageImpl instead of the server-related
> >> LargeServerMessageImpl with a very similar result. Does that implementation
> >> fit the simulated use case (sending via Core -> receiving via Qpid AMQP)
> >> better or is the explicit AMQP conversion misused?
> >>
> >> Please, see the attached patch.
> >>
> >> On Mon, Jul 18, 2022 at 3:50 PM Clebert Suconic <
> >> clebert.suco...@gmail.com> wrote:
> >>
> >>> AMQP to Core and Core to AMQP conversions expect you using JMS clients
> >>> to generate your message. There are certain caveats that both clients
> >>> will add to the messages.
> >>>
> >>>
> >>> Usually I have seen more users doing weird conversions in AMQP when
> >>> they use a C++ or non Java Client.. but on your case you used a Core
> >>> Client, using a non standard way to send a message (ServerMessage from
> >>> the client)... and it's not clear the message is correctly set for a
> >>> conversion to work.
> >>>
> >>>
> >>> I need you to provide some explanation on what you're doing.. if this
> >>> was  a way to hack a bug your saw or if this is just the way you're
> >>> using it.
> >>>
> >>>
> >>> if this is how you're actually using, I would suggest you either use
> >>> the proper APIs or if you're doing some hack for performance
> >>> consideration you have to set the message in a better way the
> >>> converters would understand...
> >>>
> >>> On Mon, Jul 18, 2022 at 9:38 AM Clebert Suconic
> >>>  wrote:
> >>> >
> >>> > Are you using the LargeServerMessageImpl on your client, or that was
> >>> > just a "hack" to reproduce your issue.
> >>> >
> >>> >
> >>> > LargeServerMessageImpl was not meant to be used on the client. But if
> >>> > you're doing that just to show something you faced in production it's
> >>> > ok.. but using the LargeServerMessageImpl to send a Client Message is
> >>> > a big not for me.
> >>> >
> >>> > The only reason we do that is for server to server transfer.
> >>> >
> >>> > On Mon, Jul 18, 2022 at 7:39 AM Andy Yar  wrote:
> >>> > >
> >>> > > Hello,
> >>> > > Yes, the 2.23.1 test instance was freshly created.
> >>> > >
> >>> > > I've attached a test as a part of ARTEMIS-3897
> >>> > > . I hope it
> >>> helps.
> >>> > >
> >>> > >
> >>> > > On Sat, Jul 16, 2022 at 5:21 PM Clebert Suconic <
> >>> clebert.suco...@gmail.com>
> >>> > > wrote:
> >>> > >
> >>> > > > Did you start with fresh data on 2.23.1.
> >>> > > >
> >>> > > > If you did please provide a self enclosing test reproducing your
> >>> issue.
> >>> > > >
> >>> > > > On Fri, Jul 15, 2022 at 4:29 AM Andy Yar 
> >>> wrote:
> >>> > > >
> >>> > > > > A quick test using 2.23.1 results in the same error payload being
> >>> > > > received:
> >>> > > > >
> >>> > > > > "Message(address='test', durable=True, priority=4,
> >>> > > > > annotations=AnnotationDict({symbol('x-opt-jms-dest'): byte(0),
> >>> > > > > symbol('x-opt-jms-msg-type'): byte(0)}),
> >>> > > > > properties={'JMSXDeliveryCount': None, '_AMQ_LARGE_SIZE': 67},
> >>> > > > > body='Conversion to AMQP error: Error reading in simpleString,
> >>> > > > > length=1330464032 is greater than readableBytes=62')"
> >>> > > > >
> >>> > > > > Best regards
> >>> > > > >
> >>> > > > > On Thu, Jul 14, 2022 at 9:18 PM Clebert Suconic
> >>> > > > >  wrote:
> >>> > > > > >
> >>> > > > > > There's been a few fixes in AMQP Large message.
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > More prominently a fix with the JDBC implementation between
> >>> 2.17 and
> >>> > > > > HEAD.
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > I would definitely recommend you to upgrade.
> >>> > > > > >
> >>> > > > > > On Thu, Jul 14, 2022 at 10:26 AM Justin Bertram <
> >>> jbert...@apache.org>
> >>> > > > > wrote:
> >>> > > > > > >
> >>> > > > > > > I would expect this to work. 

Re: Artemis - Large Message - Core => AMQP

[Robbie Gemmell]

Are you using StreamMessage because you think it will enable
'steaming'? If so I wouldnt bother, the Stream name isnt related, its
just a JMS message type name meaning there is a list/sequence of
things in it. Previously you just seemed to want to send text/bytes.

For the Core client side you can see
https://activemq.apache.org/components/artemis/documentation/latest/large-messages.html

For the broker, it would ordinarily treat the large message as a
chunked stream if doing e.g core->core, or amqp->amqp...but in this
case having to do core->amqp means the broker will necessarily have to
convert the message and in doing so it will load the entire message.

(It seems like its that last step currently not handling your sent
Core messages, because you are sending raw Core payloads that dont
match the JMS style Core message structure the brokers core->AMQP
converter is geared around, meaning it falls back to one that tries to
convert it as a string, which presumably fails due to starting to read
your bare payload as a size indicator)

On Mon, 25 Jul 2022 at 06:40, Jan Šmucr  wrote:
>
> Thank you for the feedback.
> So what would this be the proper way of streaming files (if the code below is 
> correct)?
>
>   final String body = "foo";
>
> try (Connection connection = createConnection()) {
>  Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
>  MessageProducer producer = 
> session.createProducer(session.createQueue(getQueueName()));
>  StreamMessage message = session.createStreamMessage();
>  message.writeBytes(body.getBytes());
>  producer.send(message);
>   }
>
>   AmqpClient client = createAmqpClient();
>   AmqpConnection amqpConnection = addConnection(client.connect());
>   AmqpSession amqpSession = amqpConnection.createSession();
>   AmqpReceiver receiver = amqpSession.createReceiver(getQueueName());
>   receiver.flow(100);
>   AmqpMessage amqpMessage = receiver.receive(1, TimeUnit.SECONDS);
>   Assert.assertNotNull(amqpMessage);
>   Assert.assertEquals(body, new String(((Binary) ((AmqpSequence) 
> amqpMessage.getWrappedMessage().getBody()).getValue().get(0)).getArray()));
>
> We want to stream the payloads due to the fact that these can take up to 
> hundreds of megabytes.
>
> Thank you.
> Jan
>
> From: Clebert Suconic
> Sent: sobota 23. července 2022 20:50
> To: users@activemq.apache.org
> Subject: Re: Artemis - Large Message - Core => AMQP
>
> We could look at enhancing the converters.  But the best would be to change
> your producer to have the exact format the converter would have.
>
> On Sat, Jul 23, 2022 at 2:41 PM Clebert Suconic 
> wrote:
>
> > Change your message in a way is compatible ?
> >
> > On Fri, Jul 22, 2022 at 3:36 PM Jan Šmucr 
> > wrote:
> >
> >> The reason for this is that there's a whole infrastructure built using
> >> the core protocol, and now we need to connect a Python-based Lambda capable
> >> of receiving large messages. Is there any other, core-compatible method?
> >>
> >> Jan
> >>
> >> Dne 22. 7. 2022 21:21 napsal uživatel Clebert Suconic <
> >> clebert.suco...@gmail.com>:
> >> If you expect conversions to happen, you have to send messages from
> >> qpid-ms or core-jms client.
> >>
> >>
> >> On the case:
> >>
> >>
> >> ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory();
> >> Connection conn = factory.createConnection(...);
> >> Session session = conn.createSession(...)
> >> Producer producer = session.createProducer();
> >> producer.send(session.createTextMessage(YOUR-LARGE-BODY-GOES-HERE);
> >>
> >>
> >>
> >> Then the conversion from Core to AMQP should happen fine when you
> >> receive the message on the other side at your Python client.
> >>
> >>
> >>
> >> If you really must use the Core-API, then you will need to hack your
> >> way in and find what the JMS client would do.. but at that point it's
> >> just a non standard way of doing this... You would need to have a very
> >> good reason to not do the right thing on this case.
> >>
> >> On Fri, Jul 22, 2022 at 3:00 PM Clebert Suconic
> >>  wrote:
> >> >
> >> > If you’re not using qpid JMS it will not work.
> >> >
> >> > On Fri, Jul 22, 2022 at 8:06 AM Andy Yar  wrote:
> >> >>
> >> >> There is another attempt employing AMQP test structures. It produces
> >> the same incorrect message body.
> >> >>
> >> >> On Fri, Jul 22, 2022 at 12:21 PM Andy Yar  wrote:
> >> >>>
> >> >>> Hello,
> >> >>> Using the LargeServerMessageImpl was just an attempt providing a
> >> seemingly easy way to introduce a kind of Large Message into the test. I'm
> >> not familiar with the code base at all - so I simply tried to somehow
> >> provide the requested test replicating my "sending via Core -> receiving
> >> via Qpid" issue. The same applies to the explicit AMQP conversion - the
> >> encountered error simply pointed on it. Is there an intended "te

Re: Artemis - Large Message - Core => AMQP

[Robbie Gemmell]

By "in Java" I assume you more specifically mean 'using the same Core
client as the existing senders/receivers' ?

On Mon, 25 Jul 2022 at 11:10, Jan Šmucr  wrote:
>
> > For the broker, it would ordinarily treat the large message as a
> > chunked stream if doing e.g core->core, or amqp->amqp...but in this
> > case having to do core->amqp means the broker will necessarily have to
> > convert the message and in doing so it will load the entire message.
>
> I think this is exactly what we needed to know to drop Python support and 
> create the Lambda in Java. Thank you! 😊
>
> Jan
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: pondělí 25. července 2022 12:05
> To: users@activemq.apache.org<mailto:users@activemq.apache.org>
> Subject: Re: Artemis - Large Message - Core => AMQP
>
> Are you using StreamMessage because you think it will enable
> 'steaming'? If so I wouldnt bother, the Stream name isnt related, its
> just a JMS message type name meaning there is a list/sequence of
> things in it. Previously you just seemed to want to send text/bytes.
>
> For the Core client side you can see
> https://activemq.apache.org/components/artemis/documentation/latest/large-messages.html
>
> For the broker, it would ordinarily treat the large message as a
> chunked stream if doing e.g core->core, or amqp->amqp...but in this
> case having to do core->amqp means the broker will necessarily have to
> convert the message and in doing so it will load the entire message.
>
> (It seems like its that last step currently not handling your sent
> Core messages, because you are sending raw Core payloads that dont
> match the JMS style Core message structure the brokers core->AMQP
> converter is geared around, meaning it falls back to one that tries to
> convert it as a string, which presumably fails due to starting to read
> your bare payload as a size indicator)
>
> On Mon, 25 Jul 2022 at 06:40, Jan Šmucr  wrote:
> >
> > Thank you for the feedback.
> > So what would this be the proper way of streaming files (if the code below 
> > is correct)?
> >
> >   final String body = "foo";
> >
> > try (Connection connection = createConnection()) {
> >  Session session = connection.createSession(false, 
> > Session.AUTO_ACKNOWLEDGE);
> >  MessageProducer producer = 
> > session.createProducer(session.createQueue(getQueueName()));
> >  StreamMessage message = session.createStreamMessage();
> >  message.writeBytes(body.getBytes());
> >  producer.send(message);
> >   }
> >
> >   AmqpClient client = createAmqpClient();
> >   AmqpConnection amqpConnection = addConnection(client.connect());
> >   AmqpSession amqpSession = amqpConnection.createSession();
> >   AmqpReceiver receiver = amqpSession.createReceiver(getQueueName());
> >   receiver.flow(100);
> >   AmqpMessage amqpMessage = receiver.receive(1, TimeUnit.SECONDS);
> >   Assert.assertNotNull(amqpMessage);
> >   Assert.assertEquals(body, new String(((Binary) ((AmqpSequence) 
> > amqpMessage.getWrappedMessage().getBody()).getValue().get(0)).getArray()));
> >
> > We want to stream the payloads due to the fact that these can take up to 
> > hundreds of megabytes.
> >
> > Thank you.
> > Jan
> >
> > From: Clebert Suconic<mailto:clebert.suco...@gmail.com>
> > Sent: sobota 23. července 2022 20:50
> > To: users@activemq.apache.org<mailto:users@activemq.apache.org>
> > Subject: Re: Artemis - Large Message - Core => AMQP
> >
> > We could look at enhancing the converters.  But the best would be to change
> > your producer to have the exact format the converter would have.
> >
> > On Sat, Jul 23, 2022 at 2:41 PM Clebert Suconic 
> > wrote:
> >
> > > Change your message in a way is compatible ?
> > >
> > > On Fri, Jul 22, 2022 at 3:36 PM Jan Šmucr 
> > > wrote:
> > >
> > >> The reason for this is that there's a whole infrastructure built using
> > >> the core protocol, and now we need to connect a Python-based Lambda 
> > >> capable
> > >> of receiving large messages. Is there any other, core-compatible method?
> > >>
> > >> Jan
> > >>
> > >> Dne 22. 7. 2022 21:21 napsal uživatel Clebert Suconic <
> > >> clebert.suco...@gmail.com>:
> > >> If you expect conversions to happen, you have to send messages from
> > >> qpid-ms or core-jms client.
> > >

Re: maven stuck

[Robbie Gemmell]

That is trying to download release artifacts from the snapshots
repository which it shouldnt be doing. Seems like the examples are
incorrectly [and unnecessarily] adding a repo definition that is
letting it do that. Yep, the root examples/pom.xml has some
repositories defined...delete them.

Them being there shouldnt really cause it to get 'stuck', but changing
it may help regardless if the issue is repo-specific since it then
wouldnt be looking there for the thigns it is getting stuck on.

On Thu, 8 Sept 2022 at 12:06, Benny K  wrote:
>
> Hi there,
>
> hope your doing fine.
>
> unfortunaltey no one is answering in slack
>
> just trying to have a look at the examples
>
> cd 
> /opt/apache-artemis-2.24.0/examples/features/ha/client-side-failoverlistener
> sudo mvn verify
>
> its always stuck on some downloads...
>
> [INFO] Scanning for projects...
> Downloading from apache.snapshots: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/felix/maven-bundle-plugin/5.1.6/maven-bundle-plugin-5.1.6.jar
> Downloading from apache.snapshots: 
> https://repository.apache.org/content/repositories/snapshots/org/osgi/org.osgi.core/6.0.0/org.osgi.core-6.0.0.jar
> Downloading from apache.snapshots: 
> https://repository.apache.org/content/repositories/snapshots/biz/aQute/bnd/biz.aQute.bndlib/6.2.0/biz.aQute.bndlib-6.2.0.jar
>
> If i restart its always stuck on another download...
>
> ...
> Downloading from apache.snapshots: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/maven-compat/3.3.9/maven-compat-3.3.9.jar
>
> or
>
> ...
> Downloading from apache.snapshots: 
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/shared/maven-dependency-tree/3.0/maven-dependency-tree-3.0.jar
>
>
> or
>
> ...
> Downloading from apache.snapshots: 
> https://repository.apache.org/content/repositories/snapshots/org/jdom/jdom/1.1/jdom-1.1.jar
>
>
>
> Whats cooking here? Internet-Connection works fine so far, no problems in 
> "daily business"  ...
> Thanks for help :-)
>
> Best Regards
> Benjamin
>
>

Re: maven stuck

[Robbie Gemmell]

I looked into why the repository definition was there originally and
decided to update the examples root pom to just disable looking at the
snapshots repo for release artifacts, which it should never be doing:
https://github.com/apache/activemq-artemis/commit/065bfe14f532858f2c2a20b0afb1a226b08ce013

For a released example, like you are building, just deleting the
repositories definition entirely is also equivalent to that since it
will have no snapshots in use.

On Thu, 8 Sept 2022 at 15:00, Robbie Gemmell  wrote:
>
> That is trying to download release artifacts from the snapshots
> repository which it shouldnt be doing. Seems like the examples are
> incorrectly [and unnecessarily] adding a repo definition that is
> letting it do that. Yep, the root examples/pom.xml has some
> repositories defined...delete them.
>
> Them being there shouldnt really cause it to get 'stuck', but changing
> it may help regardless if the issue is repo-specific since it then
> wouldnt be looking there for the thigns it is getting stuck on.
>
> On Thu, 8 Sept 2022 at 12:06, Benny K  wrote:
> >
> > Hi there,
> >
> > hope your doing fine.
> >
> > unfortunaltey no one is answering in slack
> >
> > just trying to have a look at the examples
> >
> > cd 
> > /opt/apache-artemis-2.24.0/examples/features/ha/client-side-failoverlistener
> > sudo mvn verify
> >
> > its always stuck on some downloads...
> >
> > [INFO] Scanning for projects...
> > Downloading from apache.snapshots: 
> > https://repository.apache.org/content/repositories/snapshots/org/apache/felix/maven-bundle-plugin/5.1.6/maven-bundle-plugin-5.1.6.jar
> > Downloading from apache.snapshots: 
> > https://repository.apache.org/content/repositories/snapshots/org/osgi/org.osgi.core/6.0.0/org.osgi.core-6.0.0.jar
> > Downloading from apache.snapshots: 
> > https://repository.apache.org/content/repositories/snapshots/biz/aQute/bnd/biz.aQute.bndlib/6.2.0/biz.aQute.bndlib-6.2.0.jar
> >
> > If i restart its always stuck on another download...
> >
> > ...
> > Downloading from apache.snapshots: 
> > https://repository.apache.org/content/repositories/snapshots/org/apache/maven/maven-compat/3.3.9/maven-compat-3.3.9.jar
> >
> > or
> >
> > ...
> > Downloading from apache.snapshots: 
> > https://repository.apache.org/content/repositories/snapshots/org/apache/maven/shared/maven-dependency-tree/3.0/maven-dependency-tree-3.0.jar
> >
> >
> > or
> >
> > ...
> > Downloading from apache.snapshots: 
> > https://repository.apache.org/content/repositories/snapshots/org/jdom/jdom/1.1/jdom-1.1.jar
> >
> >
> >
> > Whats cooking here? Internet-Connection works fine so far, no problems in 
> > "daily business"  ...
> > Thanks for help :-)
> >
> > Best Regards
> > Benjamin
> >
> >

Re: Is Artemis Production Ready?

[Robbie Gemmell]

Couple minor corrections for anyone else reading later..

On Mon, 26 Sept 2022 at 14:15, Clebert Suconic
 wrote:
>
> the major bit from the release (2) only tells you about the API. Currently
> version 2 will be version 2 as long as we keep the API compatible with
> previous releases. (When we make it 3.0 it means we can remove a few
> deprecated methods and other stuff)
>
>
> The second bit, 2.26.0 (26), means we had ** Twenty Six ** releases fixing
> bugs and improvements since we released the very first 2.0 back in 2017:
> https://github.com/apache/activemq-artemis/releases/tag/2.0.0
>

Due to 2.y.z releases as well, it is actually now 34 releases since 2.0.0.

> ActiveMQ Artemis was initially donated from HornetQ, and back then we made
> a  roadmap for features we must implement to get the same features from
> ActiveMQ. I believe at this point we are already beyond.. and that page
> needs some updating probably to reflect the current state.
>
> Also, to talk about production ready quality, the codebase of ActiveMQ
> Artemis was donated to ActiveMQ back in 2017 from HornetQ. It is a very
> stable codebase. I have myself dedicated the past 14 years of my profession
> to this codebase... along other developers who I highly consider, and many
> other open source contributors... So it is definitely production quality.

It was late 2014 for the donation, 2015 for the Artemis 1.0.0 release,
and then 2017 had the Artemis 2.0.0 release.

>
> Talking about that, I'm releasing 2.26.0 today.
>
> On Mon, Sep 26, 2022 at 6:12 AM Mark Johnson 
> wrote:
>
> > Although Artemis is at Release 2, I cannot find a direct statement in the
> > online documentation that Artemis is production ready. In contrast, this
> > page suggests that Artemis is *not* production ready
> > https://activemq.apache.org/activemq-artemis-roadmap.
> >
> >
> >
> > Naturally, I must provide evidence that Artemis is considered production
> > ready by the ActiveMQ team before investing any further effort in deploying
> > and testing Artemis to replace Classic.
> >
> >
> >
> > We are considering Artemis simply because the reporting performance of
> > Artemis is significantly higher than Classic.
> >
> >
> >
> >
> >
> > *  Mark*
> >
> >
> >
> > *Johnson*
> >
> >   Principal Product Architect
> >
> >
> >
> >   Flooid, PCMS House, Torwood Close
> >
> >   Westwood Business Park
> >
> >   Coventry, CV4 8HX, United Kingdom
> >
> >   T: +442475269508
> >
> >   M: 07764305692
> >
> >   E: mark.john...@flooid.com
> >
> > *  flooid.com *
> >
> > *Click here to send me something sensitive or securely!
> > *
> >
> > [image: Download now]
> > 
> >
> > The information contained in this e-mail is intended only for the person
> > or entity to which it is addressed and may contain confidential and/or
> > privileged material. If you are not the intended recipient of this e-mail,
> > the use of this information or any disclosure, copying or distribution is
> > prohibited and may be unlawful. If you received this in error, please
> > contact the sender and delete the material from any computer. The views
> > expressed in this e-mail may not necessarily be the views of Flooid Ltd and
> > should not be taken as authority to carry out any instruction contained.
> > Flooid Ltd reserves the right to monitor and examine the content of all
> > e-mails. Flooid Ltd is a company registered in England and Wales with
> > company number 1459419 whose registered office is at PCMS House, Torwood
> > Close, Westwood Business Park, Coventry CV4 8HX, United Kingdom. VAT No: GB
> > 705338743.
> >
> >
> >
>
>
> --
> Clebert Suconic

Re: Processing only one message

[Robbie Gemmell]

If you only want to get a single message it might make more sense to use
[possibly non-prefetching if really only wanting 1 message]
consumer.receive(..) style calls rather than a MessageListener.

Opening and closing a consumer and session per-message is quite
inefficient. Are you also closing the connection after each message, or
does the application reuse it to create a new session and consumer+listener
for future work? If the latter it definitely makes sense to just leave the
consumer open and reuse it to get each message in turn. Depending on the
number of consumers and whether they are competing, it may even make sense
to actually use prefetching at that point too.

The reason the session.close() throws is that the original JMS 1.1 spec
described it such that the client should effectively deadlock itself in
that situation. JMS 2 changed the spec description to say it could throw,
as many impls did, or could close, but since it isn't portable as there is
different behaviour, doing so should be avoided.

That said, calling consumer.close() should work, its possible there is a
bug there, depending on what you are doing overall.

You dont say what ack mode you are using. The message.acknowledge() method
is to be ignored for anything but use of the CLIENT_ACK session mode (or
the client has an individual-ack extension/non-JMS ack mode too), at which
point note that it acks all prior messages received on the session, not
just the message it is called on (unless using the extension individual ack
mode is being used, when will only do the message its called on). Though
those would be effectively the same if you only get 1 message at a time.

On Thu, 29 Sept 2022 at 23:01, John Lilley
 wrote:

> We have an application that should read a single message from a queue (a
> “job” queue) and then stop processing more messages.  Think of it as a
> “batch request”.  This is entirely using the JMS driver. Is there a good
> pattern for this?
>
>
>
> Under ActiveMQ 5, I call consumer.close(), session.close() from
> onMessage() and that works fine.  However, session.close() is not allowed
> under Artemis (and maybe it was always wrong).
>
>
>
> I’ve tried calling only consumer.close(), and leave the session open.  But
> the message is not ACked.  Explicitly calling message.acknowledge() doesn’t
> work either, because it gets to >>> and individualAck is false:
>
>
>
> *public void *acknowledge() *throws *JMSException {
>*if *(*session *!= *null*) {
>   *try *{
>  *if *(*session*.isClosed()) {
> *throw *ActiveMQClientMessageBundle.*BUNDLE*.sessionClosed();
>  }
> >>> *if *(*individualAck*) {
> *message*.individualAcknowledge();
>  }
>
>
>
> Going back to the original question, what is the recommended pattern for
> this?
>
>
>
> Thanks
>
> john
>
> [image: rg] 
>
> John Lilley
>
> Chief Architect, Redpoint Global Inc.
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is
> confidential and is intended solely for the use of the individual(s) to
> whom it is addressed. If you believe you received this e-mail in error,
> please notify the sender immediately, delete the e-mail from your computer
> and do not copy, print or disclose it to anyone else. If you properly
> received this e-mail as a customer, partner or vendor of Redpoint, you
> should maintain its contents in confidence subject to the terms and
> conditions of your agreement(s) with Redpoint.
>

Re: Processing only one message

[Robbie Gemmell]

Possibly, it's not something I've tried with the Artemis client, I was just
mainly pointing out JMS says acknowledge() does nothing if you aren't using
the click-ack mode its for. Identifying if there really is a bug with the
close-in-auto-ack-listener and perhaps fixing it might be another route.

On Fri, 30 Sept 2022 at 14:51, John Lilley
 wrote:

> Robbie,
>
>
>
> I am using auto-ack mode generally.  So perhaps one solution is to make
> this consumer manual-ACK instead?  I’ll try that.  If it works it will be
> easier than changing our code to use consumer.receive().
>
> Thanks
>
> john
>
>
>
>
> [image: rg] <https://www.redpointglobal.com/>
>
> John Lilley
>
> Chief Architect, Redpoint Global Inc.
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> *From:* Robbie Gemmell 
> *Sent:* Friday, September 30, 2022 6:49 AM
> *To:* users@activemq.apache.org
> *Subject:* Re: Processing only one message
>
>
>
>  [Caution] This email is from an external source. Please use caution
> responding, opening attachments or clicking embedded links. 
>
>
>
> If you only want to get a single message it might make more sense to use
> [possibly non-prefetching if really only wanting 1 message]
> consumer.receive(..) style calls rather than a MessageListener.
>
>
>
> Opening and closing a consumer and session per-message is quite
> inefficient. Are you also closing the connection after each message, or
> does the application reuse it to create a new session and consumer+listener
> for future work? If the latter it definitely makes sense to just leave the
> consumer open and reuse it to get each message in turn. Depending on the
> number of consumers and whether they are competing, it may even make sense
> to actually use prefetching at that point too.
>
>
>
> The reason the session.close() throws is that the original JMS 1.1 spec
> described it such that the client should effectively deadlock itself in
> that situation. JMS 2 changed the spec description to say it could throw,
> as many impls did, or could close, but since it isn't portable as there is
> different behaviour, doing so should be avoided.
>
>
>
> That said, calling consumer.close() should work, its possible there is a
> bug there, depending on what you are doing overall.
>
>
>
> You dont say what ack mode you are using. The message.acknowledge() method
> is to be ignored for anything but use of the CLIENT_ACK session mode (or
> the client has an individual-ack extension/non-JMS ack mode too), at which
> point note that it acks all prior messages received on the session, not
> just the message it is called on (unless using the extension individual ack
> mode is being used, when will only do the message its called on). Though
> those would be effectively the same if you only get 1 message at a time.
>
>
>
> On Thu, 29 Sept 2022 at 23:01, John Lilley <
> john.lil...@redpointglobal.com.invalid> wrote:
>
> We have an application that should read a single message from a queue (a
> “job” queue) and then stop processing more messages.  Think of it as a
> “batch request”.  This is entirely using the JMS driver. Is there a good
> pattern for this?
>
>
>
> Under ActiveMQ 5, I call consumer.close(), session.close() from
> onMessage() and that works fine.  However, session.close() is not allowed
> under Artemis (and maybe it was always wrong).
>
>
>
> I’ve tried calling only consumer.close(), and leave the session open.  But
> the message is not ACked.  Explicitly calling message.acknowledge() doesn’t
> work either, because it gets to >>> and individualAck is false:
>
>
>
> *public void *acknowledge() *throws *JMSException {
>*if *(*session *!= *null*) {
>   *try *{
>  *if *(*session*.isClosed()) {
> *throw *ActiveMQClientMessageBundle.*BUNDLE*.sessionClosed();
>  }
> >>> *if *(*individualAck*) {
> *message*.individualAcknowledge();
>  }
>
>
>
> Going back to the original question, what is the recommended pattern for
> this?
>
>
>
> Thanks
>
> john
>
>
>
> [image: rg]
> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.redpointglobal.com%2f&c=E,1,0ZDntuxk_EAfCKQLGnMBAyrhnrNZ9KcKhTj_3e7rK3jtFtz3NjCpKV2H_AkznQUD94jByfxPdpOf109Y27PGyw-62M1Pwd77UKKfeOg0BsADuKvpDZFFjEQr&typo=1>
>
> *John Lilley *
>
> *Chief Architect, Redpoint Global Inc. *
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointgl

Re: Disabling prefetch

[Robbie Gemmell]

I think the suggestion was as a potential workaround for
close-inside-auto-ack-listener behaviour, since it then wouldnt be trying
to close within the listener. However it is a bug if that is not working
(you should probably raise a JIRA with a minimal reproducer of your issue).
Even if you did close from another thread you would also presumably have to
stop the connection first also for prefetching to not then come into play
when onMessage had completed.

On Mon, 3 Oct 2022 at 14:55, John Lilley
 wrote:

> Clebert,
>
>
>
> Thanks for the update.  But I don’t understand the advantage of closing
> the consumer in a background thread.  Is it potentially long-running?
>
>
>
> john
>
>
>
>
> [image: rg] 
>
> John Lilley
>
> Chief Architect, Redpoint Global Inc.
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> *From:* Clebert Suconic 
> *Sent:* Sunday, October 2, 2022 9:30 AM
> *To:* users@activemq.apache.org
> *Subject:* Re: Disabling prefetch
>
>
>
>  [Caution] This email is from an external source. Please use caution
> responding, opening attachments or clicking embedded links. 
>
>
>
> singleThreadExecutor.execute (() -> this.closeConsumer(consumer));
>
>
>
> private void closeConsumer(MessageConsumer consumer) {
>
> try {
>
>  consumer.close();
>
>}
>
>   catch (Exception e) {
>
>  logger.warn(e.getMessage, e);
>
>   }
>
> }
>
>
>
>
>
> A good thing of using the listener still is that you save some threads in
> your client.
>
>
>
>
>
> if you close from an executor, you're safe.
>
>
>
> On Sat, Oct 1, 2022 at 3:12 PM John Lilley <
> john.lil...@redpointglobal.com.invalid> wrote:
>
> FYI, I developed an aversion to using receive() back when I was originally
> building our POC with RabbitMQ and trying to build our framework around
> receive() instead of onMessage(), but found that RabbitMQ’s JMS receive()
> implementation was broken.  Eventually we decided that ActiveMQ was a
> better choice, but our use of onMessage() was by then solidified.
>
>
>
> Cheers,
>
> john
>
>
>
>
>
> [image: rg]
> 
>
> *John Lilley *
>
> *Chief Architect, Redpoint Global Inc. *
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> *From:* John Lilley 
> *Sent:* Saturday, October 1, 2022 12:07 PM
> *To:* users@activemq.apache.org
> *Subject:* RE: Disabling prefetch
>
>
>
>  [Caution] This email is from an external source. Please use caution
> responding, opening attachments or clicking embedded links. 
>
>
>
> Understood… unfortunately we have a framework that generates code using
> onMessage() and it is a matter of expedience not to change that whole
> framework right now.  However I would like to change it to use receive()
> once the rest of our Artemis migration is validated.
>
>
>
> john
>
>
>
>
>
>
> 
>
> *John Lilley
> *
>
> *Chief Architect, Redpoint Global Inc.
> *
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
> 
>
> *M: +1 7209385761 | john.lil...@redpointglobal.com
> *
>
>
>
>
> *From: Clebert Suconic  Sent: Friday, September
> 30, 2022 9:01 PM To: users@activemq.apache.org Subject: Re: Disabling
> prefetch
> *
>
>
> 
>
>  [Caution] This email is from an external source. Please use caution
> respondin

Re: Disabling prefetch

[Robbie Gemmell]

It should work as the 2.0+ specs were specifically updated to say that you
can close the consumer inside its own MessageListener and onMessage will
'complete normally', which in this case would involve acking the message
for auto-ack. That was later called out specifically:

"If the session mode is AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE then any
messages delivered to the application will be automatically acknowledged as
normal."

On Mon, 3 Oct 2022 at 22:35, John Lilley
 wrote:

> Robbie,
>
>
>
> Ah I see.  Yes, I don’t think closing in the background works for my case,
> because the whole point is closing before the next message is delivered to
> get the “handle only one message” behavior.
>
>
>
> Closing the consumer does “work” in the sense that it stops the consumer,
> but it has a side-effect of disabling the auto-ACK before the onMessage()
> returns, so the message is delivered again (to another consumer).
>
>
>
> I don’t know enough about the JMS spec to say what should work and what is
> bug.  If you think that close-consumer-from-inside-onMessage should work, I
> can find a simple project to reproduce it for a bug report.
>
>
>
> Thanks
>
> john
>
>
>
>
> [image: rg] <https://www.redpointglobal.com/>
>
> John Lilley
>
> Chief Architect, Redpoint Global Inc.
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> *From:* Robbie Gemmell 
> *Sent:* Monday, October 3, 2022 11:05 AM
> *To:* users@activemq.apache.org
> *Subject:* Re: Disabling prefetch
>
>
>
>  [Caution] This email is from an external source. Please use caution
> responding, opening attachments or clicking embedded links. 
>
>
>
> I think the suggestion was as a potential workaround for
> close-inside-auto-ack-listener behaviour, since it then wouldnt be trying
> to close within the listener. However it is a bug if that is not working
> (you should probably raise a JIRA with a minimal reproducer of your issue).
> Even if you did close from another thread you would also presumably have to
> stop the connection first also for prefetching to not then come into play
> when onMessage had completed.
>
>
>
> On Mon, 3 Oct 2022 at 14:55, John Lilley <
> john.lil...@redpointglobal.com.invalid> wrote:
>
> Clebert,
>
>
>
> Thanks for the update.  But I don’t understand the advantage of closing
> the consumer in a background thread.  Is it potentially long-running?
>
>
>
> john
>
>
>
>
>
> [image: rg]
> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.redpointglobal.com%2f&c=E,1,Yp7nAk12BLQ7eR6aLI1gLChiMcvzQ6eVHnANWYybcyE1CSKfDDZVWk1MokPKXHdacLDOFFe-j5itb6sAf6pnir6DXh0PHtuKSyULm1n1QXbBtgi_Bo7TSCLFayg,&typo=1>
>
> *John Lilley *
>
> *Chief Architect, Redpoint Global Inc. *
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> *From:* Clebert Suconic 
> *Sent:* Sunday, October 2, 2022 9:30 AM
> *To:* users@activemq.apache.org
> *Subject:* Re: Disabling prefetch
>
>
>
>  [Caution] This email is from an external source. Please use caution
> responding, opening attachments or clicking embedded links. 
>
>
>
> singleThreadExecutor.execute (() -> this.closeConsumer(consumer));
>
>
>
> private void closeConsumer(MessageConsumer consumer) {
>
> try {
>
>  consumer.close();
>
>}
>
>   catch (Exception e) {
>
>  logger.warn(e.getMessage, e);
>
>   }
>
> }
>
>
>
>
>
> A good thing of using the listener still is that you save some threads in
> your client.
>
>
>
>
>
> if you close from an executor, you're safe.
>
>
>
> On Sat, Oct 1, 2022 at 3:12 PM John Lilley <
> john.lil...@redpointglobal.com.invalid> wrote:
>
> FYI, I developed an aversion to using receive() back when I was originally
> building our POC with RabbitMQ and trying to build our framework around
> receive() instead of onMessage(), but found that RabbitMQ’s JMS receive()
> implementation was broken.  Eventually we decided that ActiveMQ was a
> better choice, but our use of onMessage() was by then solidified.
>
>
>
> Cheers,
>
> john
>
>
>
>
>
>
> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.redpointglobal.com%2f&c=E,1,XBb7J1zWOWMyAUA7dGhE-9SZGlTyku4bePaCpz1XI2jn3EqgbeLWjKdQplligQi891zLImmKN-IqJvqig5ddmcYN6P0oAUTKFNQuwJWUNA,,&typo=1>
>
> *John Lilley
> <https://linkprotect.cudasvc.com/url?a=htt

Re: ClassCastException when creating a new topic

[Robbie Gemmell]

A very similar report came in a couple months ago, and the reason was
that the session (/children) was incorrectly being used from multiple
threads, causing responses operations to 'overlap' and leading to a
ClassCastException when the mismatching responses for a different
operation arrived.

On Thu, 13 Oct 2022 at 20:36, Justin Bertram  wrote:
>
> If you are able to reproduce with 2.26.0 please follow up with a Jira [1],
> and attach the test you're using to reproduce it (or some other equivalent
> way to reproduce the CCE). Thanks!
>
>
> Justin
>
> [1] https://issues.apache.org/jira/browse/ARTEMIS
>
> On Thu, Oct 13, 2022 at 2:31 PM Thorsten Meinl 
> wrote:
>
> > Am Donnerstag, dem 13.10.2022 um 11:38 -0500 schrieb Justin Bertram:
> > > It looks like perhaps the responses are being read by the client out
> > > of order or something like that. Are you using both the core JMS
> > > client and broker from 2.24.0?
> > Yes, both client and broker are 2.24.0.
> >
> > > How often do you see this? Have you tried reproducing with the latest
> > > release (i.e. 2.26.0)?
> > Very infrequently actually. We have automated tests and they fail once
> > every few days with this message. So in less than 1 out of 1000 I would
> > say (very rough guess).
> >
> > I can try with 2.26.0.
> >
> >
> > > On Thu, Oct 13, 2022 at 9:51 AM Thorsten Meinl
> > > 
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Very occasionally we get the following exception when creating a
> > > > new
> > > > topic in Artemis (2.24.0):
> > > >
> > > > Caused by: java.lang.ClassCastException: class
> > > > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.Null
> > > > Resp
> > > > onseMessage_V2 cannot be cast to class
> > > > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.Sess
> > > > ionB
> > > > indingQueryResponseMessage_V4
> > > > (org.apache.activemq.artemis.core.protocol.core.impl.wireformat.Nul
> > > > lRes
> > > > ponseMessage_V2 and
> > > > org.apache.activemq.artemis.core.protocol.core.impl.wireformat.Sess
> > > > ionB
> > > > indingQueryResponseMessage_V4 are in unnamed module of loader
> > > > io.quarkus.bootstrap.classloading.QuarkusClassLoader @3bf0cb2d)
> > > > at
> > > > org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSession
> > > > Cont
> > > > ext.addressQuery(ActiveMQSessionContext.java:413)
> > > > at
> > > > org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.addr
> > > > essQ
> > > > uery(ClientSessionImpl.java:794)
> > > > at
> > > > org.apache.activemq.artemis.jms.client.ActiveMQSession.lookupTopic(
> > > > Acti
> > > > veMQSession.java:1325)
> > > > at
> > > > org.apache.activemq.artemis.jms.client.ActiveMQSession.internalCrea
> > > > teTo
> > > > pic(ActiveMQSession.java:554)
> > > > at
> > > > org.apache.activemq.artemis.jms.client.ActiveMQSession.createTopic(
> > > > Acti
> > > > veMQSession.java:542)
> > > > at
> > > > org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createTop
> > > > ic(A
> > > > ctiveMQJMSContext.java:418)
> > > >
> > > > Any hints what could be the problem?
> > > >
> > > > Thanks,
> > > >
> > > > Thorsten
> > > >
> > > > --
> > > > Dr.-Ing. Thorsten Meinl
> > > > KNIME AG
> > > > Talacker 50
> > > > 8001 Zurich, Switzerland
> > > >
> > > >
> > > >
> >
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> >
> >
> >

Re: Mirror compatibility across versions

[Robbie Gemmell]

That helper command doesnt exist yet as Clebert said since the idea
only came from discussing something else the other day, but the
pre-existing logging related changes coming for 2.27.0 are covered in
the docs along with diffs of the script changes from 2.26.0, you can
see the current source version of those docs at
https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/en/versions.md#2270
. They will be updated to reference the helper once it exits.

On Thu, 13 Oct 2022 at 18:52, Stephen Baker
 wrote:
>
> Because bin/artemis includes references to the jboss logmanager causing 
> artemis to fail on startup
>
> Diffing my two instances I see:
> # Set Defaults Properties
> ARTEMIS_LOGGING_CONF="$ARTEMIS_INSTANCE_ETC_URI/logging.properties"
> ARTEMIS_LOG_MANAGER=org.jboss.logmanager.LogManager
>
>
> # finding the Log Manager
> LOG_MANAGER=`ls $ARTEMIS_HOME/lib/jboss-logmanager*jar 2>/dev/null`
>
> if [ -z "$LOG_MANAGER" ] ; then
>   # this is the one found when the server was created
>   LOG_MANAGER="$ARTEMIS_HOME/lib/jboss-logmanager-2.1.10.Final.jar"
> fi
>
> WILDFLY_COMMON=`ls $ARTEMIS_HOME/lib/wildfly-common*jar 2>/dev/null`
> if [ -z "$WILDFLY_COMMON" ] ; then
>   # this is the one found when the server was created
>   WILDFLY_COMMON="$ARTEMIS_HOME/lib/wildfly-common-1.5.2.Final.jar"
> fi
>
> -Xbootclasspath/a:"$LOG_MANAGER:$WILDFLY_COMMON" \
>
> and
>
> -Djava.util.logging.manager="$ARTEMIS_LOG_MANAGER" \
> -Dlogging.configuration="$ARTEMIS_LOGGING_CONF" \
>
> all have to go.
>
> I also see a change in the schema for bootstrap.xml (binding child of web), 
> and the browse permission added to management.xml
>
> Along with the new log4j.properties you mentioned
>
> Some of those changes might be earlier if they’re backwards compatible, I’ve 
> carried forward this configuration for awhile, but in particular the shell 
> script changes appear to be manditory.
>
> From: Clebert Suconic 
> Date: Thursday, October 13, 2022 at 12:49 PM
> To: users@activemq.apache.org 
> Subject: Re: Mirror compatibility across versions
> I think the record would pile up unacked at the source mirror.
>
>
> and @Stephen baker: sorry about my mistake on this fix...
>
>
> Why would the upgrade be difficult on 2.27? it's just adding a
> log4j2.properties.. everything else should be the same.
>
>
> You should probably bring a patched version yourself until we can make
> a release? I'm thinking we should make a release next week.
>
> On Thu, Oct 13, 2022 at 10:27 AM Stephen Baker
>  wrote:
> >
> > Your patch does resolve the error. Artemis 2.27 looks like it will be a 
> > difficult upgrade, I ended up making a new instance and merging config over.
> >
> > I have pasted a trace in https://issues.apache.org/jira/browse/ARTEMIS-4045
> >
> > What is the impact of this issue? I’m trying to decide whether to advise 
> > our IT team to continue with the planned upgrade or hold off until 2.27. We 
> > will definitely encounter this condition in production. From a surface 
> > reading, possibly a resource leak?
> >
> >
> >
> >
> > From: Clebert Suconic 
> > Date: Wednesday, October 12, 2022 at 9:54 PM
> > To: users@activemq.apache.org 
> > Subject: Re: Mirror compatibility across versions
> > Notice that main is now using SLF4j / log4j... (in case you manually
> > upgrade to a snapshot)
> >
> >
> > We are still working the details for an upgrade.
> >
> >
> > if you need to patch your 2.25.0 it's a straight change to make there
> >
> > On Wed, Oct 12, 2022 at 9:52 PM Clebert Suconic
> >  wrote:
> > >
> > > I don't know how I would test it yet. It's fairly late in the night
> > > for me.. I will think about it tomorrow.
> > >
> > >
> > > but here is a tentative fix:
> > >
> > > https://github.com/apache/activemq-artemis/pull/4256
> > >
> > > On Wed, Oct 12, 2022 at 9:30 PM Stephen Baker
> > >  wrote:
> > > >
> > > > That’s the full output with regular logging levels. I can reproduce at 
> > > > will so I have enabled trace level logging and pasted the result in 
> > > > https://issues.apache.org/jira/browse/ARTEMIS-4045
> > > >
> > > > Let’s take further discussion there?
> > > >
> > > > From: Clebert Suconic 
> > > > Date: Wednesday, October 12, 2022 at 9:10 PM
> > > > To: users@activemq.apache.org 
> > > > Subject: Re: Mirror compatibility across versions
> > > > is this the actual trace? or you cut some to post here?
> > > >
> > > >
> > > > Just puzzled by skipDelivery calling performAck..
> > > >
> > > > artemis-test-artemis-1-m-1   |at
> > > > org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget.lambda$performAck$2(AMQPMirrorControllerTarget.java:377)
> > > > [artemis-amqp-protocol-2.25.0.jar:2.25.0]
> > > > artemis-test-artemis-1-m-1   |at
> > > > org.apache.activemq.artemis.core.server.impl.QueueImpl$2.skipDelivery(QueueImpl.java:1203)
> > > > [artemis-server-2.25.0.jar:2.25.0]
> > > >
> > > >
> > > > can you post the full stack if this is not it?
> > > >
> > > >
> > > >

Re: Recommended way to define instance properties

[Robbie Gemmell]

2.27.0 included the addition of JAVA_ARGS_APPEND for the command run
by the startup script. You should be able to use that env variable
more simply to make additions to the startup args, e.g inline before
calling the script, since it isnt used for anything else unlike the
JAVA_ARGS one.

On Fri, 18 Nov 2022 at 15:55, Clebert Suconic  wrote:
>
> You should either keep doing these changes manually after the upgrade,
>
>
> or keep these variables in a calling script.
>
>
>
> if you can think of a better way to do this? perhaps a new properties
> files for custom modifications? but if you keep these variables in a
> caller's that's pretty much all the same.
>
>
> On Fri, Nov 18, 2022 at 10:28 AM Stephen Baker
>  wrote:
> >
> > My organization had been using artemis.profile to define additional 
> > instance parameters eg:
> >
> > RAVE_MIRROR_CONNECTION_STR=tcp://artms1.atl.raveu.net:5672
> > RAVE_MIRROR_NAME=ATL
> > RAVE_MIRROR_USER=rave
> > RAVE_MIRROR_PASSWORD=password
> > RAVE_CONFIG_DIR=/rave/artemis/deploy/example
> >
> > # Rave environment settings
> > JAVA_ARGS="$JAVA_ARGS 
> > -DraveMirrorConnectionStr=${RAVE_MIRROR_CONNECTION_STR} 
> > -DraveMirrorName=${RAVE_MIRROR_NAME} -DraveMirrorUser=${RAVE_MIRROR_USER} 
> > -DraveMirrorPassword=${RAVE_MIRROR_PASSWORD} 
> > -DraveConfigDir=${RAVE_CONFIG_DIR}"
> >
> > However the new upgrade tool removes all of these lines leading to a more 
> > complex upgrade process. What is the recommended way going forward of 
> > providing parameters for use in broker.xml for the least friction with 
> > future upgrades?
>
>
>
> --
> Clebert Suconic

Re: question on Python QpidProton with Artemis

[Robbie Gemmell]

I believe the Proton python binding wont use PLAIN if offered, unless
the connection is using TLS or it was instructed it can use it
regardless:

https://qpid.apache.org/releases/qpid-proton-0.38.0/proton/python/docs/proton.reactor.html#proton.reactor.Container.connect

"allow_insecure_mechs (bool), a flag indicating whether insecure
mechanisms, such as PLAIN over a non-encrypted socket, are allowed."

The broker defaults to offering PLAIN + ANONYMOUS, which it will keep
doing even if you only have "PropertiesLoginModule required" since
unfortunately the bits saying what SASL mechanisms to offer have
absolutely no knowledge of what JAAS login config exists and what
mechanisms can actually work. One of the more annoying things about
the use of JAAS.

You can specifically configure what mechanisms to offer however, using
the "saslMechanisms" option on the acceptor URI, e.g as you would need
to when enabling support for SCRAM-SHA-*, EXTERNAL or GSSAPI. Covered
at 
https://activemq.apache.org/components/artemis/documentation/latest/security.html

Robbie

On Tue, 17 Jan 2023 at 10:28, Dondorp, Erwin
 wrote:
>
> Hello,
>
> So far I've been happy connecting to Artemis using either the Artemis JMS 
> (CORE protocol) or with QPid JMS (AMQP protocol).
> But attempts with using Python QpidProton (AMQP protocol) are only successful 
> when an anonymous user is allowed, but I actually need username+password.
> I now did a Wireshark trace to see what happened when a username+password is 
> used:
>
> Client <---> broker
> ===
> --> Protocol header 1-0-0
> <-- Protocol header 1-0-0 sasl.mechanisms(PLAIN+ANONYMOUS)
> --> sasl.init ANONYMOUS
> <-- sasl.outcome OK
> --> Protocol header 1-0-0 open begin attach(correct client-id and correct 
> address)
> <-- Protocol header 1-0-0
> --> open close(error-desciption=NullPointerException)
> --> close
>
> First observation is that Artemis is returning "NullPointerException" in the 
> description of the 'close' sub-packet. The Artemis logfile shows a real NPE 
> in location 
> "org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.getAddress(AMQPSessionCallback.java:724)"
>  for that.
> I'm not sure whether that is a bug, or just some unpolished code.
>
> Second observation is that Artemis offers the PLAIN+ANONYMOUS mechanisms.
> But my server only has "PropertiesLoginModule required" in etc/login.config, 
> which does not actually allow anonymous login.
> I'm not sure whether that is a bug, or just an incorrect expectation from my 
> side.
>
> Does anyone have useful remarks on these 2 observations?
> Does anyone have a working Python QpidProton client that uses 
> username+password?
>
> thx,
> Erwin

Re: query regarding security issues in artemis 2.19.1 ( Java 8 )

[Robbie Gemmell]

There aren't any plans for more 2.19.x releases that I know of. 2.19.1
was released a year ago, very shortly after the initial transition to
requiring Java 11 with Artemis 2.20.0. There have been several newer
>2.20.0 releases since then, the current version being 2.27.1 (with
2.28.0 intended soon).

In general, if a given non-latest release/stream such as 2.19.1 isnt
on https://activemq.apache.org/components/artemis/download/ (or if
there, isnt noted as being the last intended release, like 2.19.1
specifically was for months) then it isnt planned for further
releases.

On Mon, 30 Jan 2023 at 06:00, Raghav Simlote
 wrote:
>
> Hello Team
>
> Is Artemis 2.19.1 with java 8  is secured with all vulnerabilities ?
>
> Regards
> Raghav Simlote
>

Re: [EXTERNAL] Re: Artemis API equivalent to ActiveMQMapMessage

[Robbie Gemmell]

Both ActiveMQ 5.x and Artemis have client jars with implementations of
the JMS MapMessage interface, that both happen to be in a class called
ActiveMQMapMessage, but they are independent implementations and live
in different java packages.

What Justin was saying is that the Artemis implementation doesnt
support 'nested lists and maps' extended functionality that 5.x impl
apparently offers. I'm not sure why he asked about that since you
didnt seem to specifically mention it in your original email, maybe
there was some other context. If you aren't using that extended
functionality then you should just be able to use the Artemis
MapMessage implementation, or indeed any JMS client impls MapMessage
that talks to the broker.

Note it is somewhat unusual for application code to directly
instantiate a JMS message implementation object like that, usually you
would do session.createMapMessage() or such like in order to create
the message object in a vendor-neutral and portable fashion, not
needing to know the name or package of the clients message
implementation class, and just using the JMS MapMessage interface for
the returned object. Which in the end is actually all your code does
use for the new mapMessage object after instantiating it, since it is
first assigned to a variable of type MapMessage (though it is unclear
what type the source 'message' object variable is).

On Mon, 30 Jan 2023 at 14:52, Gunawan, Rahman (GSFC-703.H)[Halvik
Corp]  wrote:
>
> Below is the MapMessage code:
> MapMessage mapMessage = new ActiveMQMapMessage();
> message.forEach((key, value) -> {
>   try {
> mapMessage.setObject(key, value);
>   } catch (JMSException e) {
> LOG.info("Failed to create MapMessage entry with", e);
>   }
>
> I found that ActiveMQMapMessage is under artemis in github 
> https://github.com/apache/activemq-artemis/blob/main/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQMapMessage.java.
>   Does it mean ActiveMQMapMessage still under one of the Artemis jar file?
> Thanks
>
> Regards,
> Rahman
>
> -Original Message-
> From: Justin Bertram 
> Sent: Friday, January 27, 2023 4:40 PM
> To: users@activemq.apache.org
> Subject: Re: [EXTERNAL] Re: Artemis API equivalent to ActiveMQMapMessage
>
> It's not supported currently. Is it critical for your use-case? If so, could 
> you elaborate on your use-case?
>
>
> Justin
>
> On Fri, Jan 27, 2023 at 3:28 PM Gunawan, Rahman (GSFC-703.H)[Halvik Corp] 
>  wrote:
>
> > Yes, that's correct.
> >
> > Rahman
> >
> > -Original Message-
> > From: Justin Bertram 
> > Sent: Friday, January 27, 2023 4:25 PM
> > To: users@activemq.apache.org
> > Subject: [EXTERNAL] Re: Artemis API equivalent to ActiveMQMapMessage
> >
> > Are you talking about the "extension" provided by ActiveMQ "Classic"
> > that allows one to use nested Maps and Lists inside a JMS MapMessage
> > [1] via the setObject method? If not, please clarify.
> >
> >
> > Justin
> >
> > [1]
> > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .oracle.com%2Fjavaee%2F7%2Fapi%2Fjavax%2Fjms%2FMapMessage.html&data=05
> > %7C01%7Crahman.gunawan%40nasa.gov%7C649fa57d0e0a454c161b08db00af3e29%7
> > C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638104524895912762%7CUnkno
> > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TcP%2BSiil0UzMY5C%2FYJocEa7dKDEuh2
> > 6u5t6%2BhHAZE60%3D&reserved=0
> >
> > On Fri, Jan 27, 2023 at 6:46 AM Gunawan, Rahman (GSFC-703.H)[Halvik
> > Corp] < rahman.guna...@nasa.gov.invalid> wrote:
> >
> > > We plan to migrate from ActiveMQ classic to Artemis.  What will be
> > > the Artemis API to replace org.apache.activemq.command.ActiveMQMapMessage?
> > > Thanks
> > >
> > > Regards,
> > > Rahman
> > >
> > >
> >
> >

Re: Request for details on activeMQ 5.16.6 release

[Robbie Gemmell]

You should review yes as 5.16.5 was announced as the intended final
5.16.x release, over 9 months ago as you noted. That is why it hasnt
seen the same updates 5.17.x has during that time, any coming 5.16.6
release was not originally intended to exist.

Robbie

On Sat, 11 Feb 2023 at 08:49, somasani nikhil  wrote:
>
> Thank you so much Jean, we plan to upgrade to 5.17.x series but
> unfortunately our application needs more efforts to work with JDK 11.x
> which is supported through activeMQ latest versions(5.17).
>
> We may need to review our sources again on this issue about JDK and
> activeMQ support.
>
> Appreciate your help once again.
>
> Regards,
> Nikhil Somasani
>
> On Sat, 11 Feb 2023 at 11:42 AM, Jean-Baptiste Onofré 
> wrote:
>
> > Hi Nikhil,
> >
> > following your message (in Jira) and other requests we received, we
> > prepared 5.16.6, currently on vote.
> > If the vote passes, 5.16.6 should be available at the beginning of next
> > week.
> >
> > By the way, we strongly encourage you to upgrade to ActiveMQ 5.17.x series.
> >
> > Regards
> > JB
> >
> > On Sat, Feb 11, 2023 at 5:15 AM somasani nikhil
> >  wrote:
> > >
> > > Hi Team,
> > >
> > > There have been several security fixes given after 5.16.5 which is
> > released
> > > in May 2022, I’m trying to understand the roadmap / release timelines for
> > > 5.16.6 release so that we actively looking after to update our
> > applications.
> > >
> > > Please let us know if anyone has information/ can help with this release
> > ?
> > >
> > > Thank you
> > > Nikhil Somasani
> > > --
> > > Thanks and Regards,
> > > Nikhil Somasani
> >
> --
> Thanks and Regards,
> Nikhil Somasani

Re: Help Troubleshooting ActiveMQ on AWS

[Robbie Gemmell]

The error has nothing to do with the messages or fields in them. It is
saying that a client connection is trying to use the same AMQP
container-id as another existing client connection. The broker treats
the connection container-id as the ClientID in JMS terms, only
allowing one connection to use a given value at a time.

On Thu, 23 Feb 2023 at 22:56, George Sexton
 wrote:
>
> I’m using ActiveMQ, Broker Engine Version 5.15.6 on AWS. The instance
> size is mq.t2.micro, in Single-instance broker deployment mode.
>
> A Golang application that has been working for years started
> misbehaving. The calling application is getting error messages:
>
> time="2023-02-23 21:35:17.1885" level=error msg="Retrying send"
> app=addef error="*Error{Condition: amqp:invalid-field, Description:
> Broker: xxx-xxx- - Client: 6bcc2aa9-468c-4c38-a16e-8713e6e7833b
> already connected from tcp://99.99.99.99:34834, Info:
> map[invalid-field:container-id]}" id=6bcc2aa9-468c-4c38-a16e-8713e6e7833b
>
> and:
>
> time="2023-02-23 21:35:17.1887" level=*error*msg="failed to handle ct
> deletion event" app=addef ctid=04f7519f-1125-4047-7047-c475d0ee87b2
> *error*="failed to send ct changed message: **Error*{Condition:
> amqp:invalid-field, Description: Broker: xxx-xxx-- Client:
> 6bcc2aa9-468c-4c38-a16e-8713e6e7833b already connected from tcp://
> 99.99.99.99::34834, Info: map[invalid-field:container-id]}"
> request_id=42558916-d800-485e-9abb-a2ffd156a366
>
> When I initially looked at the system, the home page showed Store
> Percent Used to be 100%. I purged the dead-letter queue, and now Store
> Percent Used shows 11%. After the purge, I rebooted the instance, but
> the application is still failed.
>
> I turned on Cloudwatch logging for AmazonMQ, and I can see the startup
> messages. From looking at the AWS article on enabling logging, INFO is
> the default log level and can’t be changed. Aside from startup, all I
> see is a few entries:
>
> Transport Connection to: tcp://10.100.16.40:33962 failed:
> org.apache.activemq.transport.InactivityIOException: Channel was
> inactive for too long |
> org.apache.activemq.broker.TransportConnection.Transport |
> AmqpInactivityMonitor Async Task:
> java.util.concurrent.ThreadPoolExecutor$Worker@47ec0444[State = -1,
> empty queue
>
> I looked at the application code, and a message from the dead-letter
> queue, and can say there is not a container-id field in them. I searched
> around and found some references to invalid-field container-id, but they
> seem to be internal references:
>
> https://issues.apache.org/jira/browse/AMQ-5591
>
> Does anyone have any ideas on how I can troubleshoot this, or areas I
> can look into? Thanks for helping!
>
>
> --
> George Sexton
> (303) 438 9585 x102
> MH Software, Inc.

Re: Exception thrown in JmsTemplate.send session close

[Robbie Gemmell]

This is a debug level log including a stack trace for reference. Its
not an exception being thrown to an application, or even logged at
error or warning level to indicate an issue to/with the applicaton. It
doesnt seem to be for indicating a problem at all and so seems fine
not to be concerned about. As you say, it seems it was also doing it
before, just at a different level.

Whatever logging implementation you are using in your application now
is handling the SLF4J loggers (which 2.27.0 changed to using, versus
its use of JBoss Logging before that) and is also configured to output
debug messages for the artemis loggers. Its not immediately clear
whether the latter is something you are doing deliberately or not,
it's often a little unusual? If you weren't similarly including a
necessary logging dep to handle the JBoss Logging loggers and
configuring it to output debug for the artemis loggers previously when
using 2.24.0, I expect you wouldnt have really seen any client logging
in comparison. I guess your not mentioning such a significant
difference would suggest that you were doing that before though.

On Tue, 28 Feb 2023 at 09:43, PETRULIS Domas
 wrote:
>
> Hi,
>
> Recently, we have updated artemis dependencies from 2.24.0 to latest 2.28.0 
> in our project. After the update we came upon a problem - we started noticing 
> exceptions being printed out in logs after JmsTemplate message send.
>
> Particular exception thrown:
> [main] DEBUG org.apache.activemq.artemis.core.client.impl.ClientSessionImpl  
> - Calling close on session ClientSessionImpl 
> [name=a3a3ffc2-b73f-11ed-af77-e86a64f1df39, username=artemis, closed=false, 
> factory = 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@13b3d178,
>  metaData=(jms-session=,)]@2fc0cc3
> [main] DEBUG org.apache.activemq.artemis.core.client.impl.ClientSessionImpl  
> - calling cleanup on ClientSessionImpl 
> [name=a3a3ffc2-b73f-11ed-af77-e86a64f1df39, username=artemis, closed=false, 
> factory = 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@13b3d178,
>  metaData=(jms-session=,)]@2fc0cc3
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:383)
> at 
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1214)
> at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:58)
> at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:33)
> at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:69)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [main] DEBUG org.apache.activemq.artemis.core.client.impl.ClientSessionImpl  
> - Session was already closed, giving up now, this=ClientSessionImpl 
> [name=a3a3ffc2-b73f-11ed-af77-e86a64f1df39, username=artemis, closed=true, 
> factory = 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@13b3d178,
>  metaData=(jms-session=,)]@2fc0cc3
>
> Started to investigate the root cause of the problem.
>
> We thought it was something to do with our configuration, however after 
> creating a new demo project with default settings and starting a freshly 
> insalled artemis broker it still seems to printout the exception after 
> message send.
>  class="org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory">
> 
> 
> 
> 
> 
> 
> 
>
> After checking why the exception was not thrown in 2.24.0 compared to 2.28.0, 
> it seems that the exception is actually thrown in the background, just not 
> printed out for DEBUG as in 2.28.0.
> As of 
> https://github.com/apache/activemq-artemis/commit/9873fccf744c0cb0a25dd905fab67ea52ef7aa7d
>  commit it changes the logging from TRACE to DEBUG in 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl#failoverOrReconnect
>  which I assume logs it.
>
> Message is sent and received correctly, it seems nothing breaks in the end, 
> just that the exception is thrown after cleaning up the session.
>
> Questions would be:
> Is the exception thrown just used for logging and should we just skip it?
> Is there some other problem we are facing which needs to be fixed so that the 
> exception is not thrown after session close?
>
> Thanks in advance!
>
> This email and any attachments are intended solely for the use of the 
> individual or entity to whom it is addressed and may be confidential and/or 
> privileged.
>
> If you are not one of the named recipients or have received this email in 
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) pleas

Re: Versions no longer supported (EOL) of ActiveMq Artemis

[Robbie Gemmell]

What you mean by 'supported' is unclear. Folks can obviously assist
with questions etc about older releases, but if you hit something
needing a code change then that code change is going to arrive in a
new current release, either the next planned minor or a patch release
if really required.

The current releases are those on the download page:
https://activemq.apache.org/components/artemis/download/

Past non-current releases are referenced from the first line of the
download page and are catalogued at:
https://activemq.apache.org/components/artemis/download/past_releases

On Thu, 2 Mar 2023 at 16:01, Rhea MOUBARAK  wrote:
>
> Hello,
>
> I am trying to look everywhere for the versions of ActiveMq Artemis that are 
> no longer supported, and I can't find any.
>
> Does any of you know which versions are not supported anymore?
>
> Thank you for your help.
>
> Best,
> Rhea MOUBARAK
>

Re: Artemis - broker.xml configuration on Docker

[Robbie Gemmell]

Tangential note that 2.19.0 is old at this point, and isnt even the
latest 2.19.x given that 2.19.1 was later released to backport some
stuff from 2.20.0 and 2.21.0. The current release is 2.28.0.

On Thu, 9 Mar 2023 at 10:04, Marko Lazić  wrote:
>
> Hello!
>
>
> I’ve built Artemis 2.19.0 image from apache/activemq-artemis: Mirror of 
> Apache ActiveMQ Artemis (github.com) 
> . I have problem with configuring 
> the broker.xml file on Docker. I want maybe to define some addresses, queues 
> and change some address settings. My intuitive try was to mount a 
> /var/lib/artemis-instance/etc/broker.xml but I've got an error on container 
> startup that the artemis executable does not exist, as mounting prevents it 
> from creating. The activemq-artemis/artemis-docker has a Mapping point 
> section but it mentions that you can mount the whole instance via 
> /var/lib/artemis-instance. I just want to change only few lines in the 
> broker.xml file. Is there a way to to mount only my custom broker.xml file on 
> startup?
>
>
>
> Kind regards
> Marko

Re: Artemis REST API

[Robbie Gemmell]

It was removed in 2.26.0 about 6 months ago, see details at
https://activemq.apache.org/components/artemis/documentation/latest/versions.html

On Thu, 9 Mar 2023 at 22:52, Thai Le  wrote:
>
> Hello,
>
> Does the REST API still exist in the latest version? I do not see it in the
> doc of 2.28.
>
> Regards
>
> Thai Le

Re: [URL Verdict: Neutral][Non-DoD Source] Re: Re: Query on OracleJava alternative for ActiveMQ

[Robbie Gemmell]

5.16.6 would use the same log4j configuration file, its still using
reload4j (log4j 1.x fork) as before.

5.17.x uses Log4j 2, so you would need to use the newer log4j2 config
file to configure things.

On Wed, 15 Mar 2023 at 16:04, ABURTO, BRUNO M CTR USAF ACC 99 RS/MPC
 wrote:
>
> 5.16.5
>
> -Original Message-
> From: Justin Bertram 
> Sent: Wednesday, March 15, 2023 8:55 AM
> To: users@activemq.apache.org
> Subject: Re: [URL Verdict: Neutral][Non-DoD Source] Re: Re: Query on 
> OracleJava alternative for ActiveMQ
>
> Looking back through the email thread I don't see a clear indication of which 
> version you're upgrading from. Can you clarify this for me?
>
>
> Justin
>
> On Wed, Mar 15, 2023 at 10:51 AM ABURTO, BRUNO M CTR USAF ACC 99 RS/MPC 
>  wrote:
>
> > Configuration file
> >
> > -Original Message-
> > From: Justin Bertram 
> > Sent: Wednesday, March 15, 2023 8:06 AM
> > To: users@activemq.apache.org
> > Subject: Re: [URL Verdict: Neutral][Non-DoD Source] Re: Re: Query on
> > OracleJava alternative for ActiveMQ
> >
> > Are you asking about the logs themselves or the Log4j configuration file?
> >
> >
> > Justin
> >
> > On Wed, Mar 15, 2023 at 9:59 AM ABURTO, BRUNO M CTR USAF ACC 99 RS/MPC
> > < bruno.aburto@us.af.mil.invalid> wrote:
> >
> > > Do old Log4j files need to be deleted after updating to 5.16.6 or 5.17.4?
> > >
> > > -Original Message-
> > > From: Justin Bertram 
> > > Sent: Tuesday, March 14, 2023 11:24 AM
> > > To: users@activemq.apache.org
> > > Subject: [URL Verdict: Neutral][Non-DoD Source] Re: Re: Query on
> > > OracleJava alternative for ActiveMQ
> > >
> > > No. As the website [1] states:
> > >
> > >   Java compatibility: 11+
> > >
> > > The latest release that is compatible with Java 8 is 5.16.6.
> > >
> > >
> > > Justin
> > >
> > > [1] https://activemq.apache.org/components/classic/download/
> > >
> > > On Tue, Mar 14, 2023 at 1:21 PM ABURTO, BRUNO M CTR USAF ACC 99
> > > RS/MPC < bruno.aburto@us.af.mil.invalid> wrote:
> > >
> > > > Can I continue to use Java 8 with version 5.17.4?
> > > >
> > > > On 2023/02/22 16:08:58 Matt Pavlovich wrote:
> > > > > Hello Jana-
> > > > >
> > > > > As far as I know, there have been no reported issues specific to
> > > > > the
> > > > recent generation of JDK releases by vendor. The most important
> > > > thing is to use latest releases to incorporate fixes— especially
> > security.
> > > > >
> > > > > JDK 11 and ActiveMQ v5.17.3 (v5.17.4 should be available in a
> > > > > few days,
> > > > as the release vote is underway)
> > > > >
> > > > > That being said, it is recommended you test your workload
> > > > > against the
> > > > JDK+ActiveMQ combination to confirm.
> > > > >
> > > > > Thank you,
> > > > > Matt Pavlovich
> > > > >
> > > > > > On Feb 22, 2023, at 1:32 AM, Jana Manju  wrote:
> > > > > >
> > > > > > Hi Team,
> > > > > >
> > > > > > We are in process of configuring ActiveMQ as message broker
> > > > > > system for
> > > > one
> > > > > > of our critical application, As JRE(Java Runtime Environment)
> > > > > > is must
> > > > for
> > > > > > ActiveMq to work, could you please confirm if following
> > > > > > approved
> > > > OpenJDK by
> > > > > > the 3rd Party Software will give same ability as Oracle Java
> > > > > > for
> > > > ActiveMQ
> > > > > > to work w.r.t its configuration and performance etc.
> > > > > >
> > > > > >  Amazon Corretto and OpenJDK
> > > > > >  Adoptium Eclipse Temurin
> > > > > >  Azul Java
> > > > >
> > > > >
> > > >
> > >
> >

Re: Payara connection pool 2.28.0

[Robbie Gemmell]

As you said, the setters presumably didnt exist before, and still
dont, soperhaps the main difference is just in the logging setup?

The old version was 2.19.1 (noted later) which used JBoss Logging,
while the newer version is 2.28.0 which now uses SLF4J API and in turn
any supporting logging implementation. If it found a logging framework
then it may just have started logging stuff that simply didnt get
shown previously.

On Wed, 19 Apr 2023 at 19:40, Justin Bertram  wrote:
>
> I wonder if the newer version of Payara is now logging warnings about the
> missing setters. The fact that they aren't there isn't new, but we can
> certainly add them. Feel free to open a Jira.
>
> As for the MDBs not receiving messages, you are probably hitting
> ARTEMIS-4188 [1].
>
>
> Justin
>
> [1] https://issues.apache.org/jira/browse/ARTEMIS-4188
>
> On Wed, Apr 19, 2023 at 11:02 AM Marko Lazić  wrote:
>
> > Hello,
> >
> >
> > The following code worked before with Payara 5.2022.2 1.8 jdk but now when
> > i upgraded to 2.28.0 artemis and Payara 5.2022.5-jdk11 it has some problems
> >
> > payara pre-boot.commands.asadmin file
> >
> > # Apache ActiveMQ Artemis
> > deploy --type rar --name artemis-rar
> > /opt/payara/deployments/artemis-rar-2.28.0.rar
> > create-resource-adapter-config  --property
> > ConnectorClassName='org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory':ConnectionParameters='host=broker;port=61616':UserName='artemis':Password='artemis'
> > artemis-rar
> > create-connector-connection-pool --raname artemis-rar
> > --connectiondefinition
> > org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactory --property
> > UserName=artemis:Password=artemis  --ping true jms/ConnectionFactoryPool
> > create-connector-resource --poolname jms/ConnectionFactoryPool
> > jms/msgConnectionFactory
> >
> >
> >
> >
> > Payara log
> >
> > [#|2023-04-19T15:52:44.487+|INFO|Payara
> > 5.2022.5|fish.payara.boot.runtime.BootCommand|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564487;_LevelValue=800;|
> >   Boot Command create-resource-adapter-config returned with result SUCCESS
> > : PlainTextActionReporterSUCCESSNo monitoring data to report.
> > |#]
> > [#|2023-04-19T15:52:44.502+|WARNING|Payara 5.2022.5|javax.enterprise.
> > resource.resourceadapter.com
> > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564502;_LevelValue=900;|
> >   RAR8000 : The method setPassword is not present in the class :
> > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory|#]
> > [#|2023-04-19T15:52:44.503+|WARNING|Payara 5.2022.5|javax.enterprise.
> > resource.resourceadapter.com
> > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564503;_LevelValue=900;|
> >   RAR7097: No setter method present for the property password in the class
> > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory|#]
> > [#|2023-04-19T15:52:44.503+|WARNING|Payara 5.2022.5|javax.enterprise.
> > resource.resourceadapter.com
> > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564503;_LevelValue=900;|
> >   RAR8000 : The method setUsername is not present in the class :
> > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory|#]
> > [#|2023-04-19T15:52:44.503+|WARNING|Payara 5.2022.5|javax.enterprise.
> > resource.resourceadapter.com
> > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564503;_LevelValue=900;|
> >   RAR7097: No setter method present for the property username in the class
> > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory|#]
> > [#|2023-04-19T15:52:44.920+|INFO|Payara
> > 5.2022.5|fish.payara.boot.runtime.BootCommand|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564920;_LevelValue=800;|
> >   Boot Command create-connector-connection-pool returned with result
> > SUCCESS : PlainTextActionReporterSUCCESSConnector connection pool
> > jms/ConnectionFactoryPool created.
> > Attempting to ping during Connector Connection Pool Creation :
> > jms/ConnectionFactoryPool - Succeeded.|#]
> > [#|2023-04-19T15:52:44.939+|INFO|Payara
> > 5.2022.5|fish.payara.boot.runtime.BootCommand|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564939;_LevelValue=800;|
> >   Boot Command create-connector-resource returned with result SUCCESS :
> > PlainTextActionReporterSUCCESSConnector resource jms/msgConnectionFactory
> > created.|#]
> >
> >
> > I noticed also some MDBs that are listening on auto-created queues do not
> > receive messages anymore
> >
> >
> > Kind regards,
> > Marko

Re: Payara connection pool 2.28.0

[Robbie Gemmell]

Actually since the logging is not from artemis itself, the last bit
probably doenst really make sense hehe.although we did also remove
the JBL usage any related JUL config around log managers etc, so the
change probably could still have an effect...albeit perhaps to make it
less likely to log such things rather than more likely.

On Thu, 20 Apr 2023 at 09:29, Robbie Gemmell  wrote:
>
> As you said, the setters presumably didnt exist before, and still
> dont, soperhaps the main difference is just in the logging setup?
>
> The old version was 2.19.1 (noted later) which used JBoss Logging,
> while the newer version is 2.28.0 which now uses SLF4J API and in turn
> any supporting logging implementation. If it found a logging framework
> then it may just have started logging stuff that simply didnt get
> shown previously.
>
> On Wed, 19 Apr 2023 at 19:40, Justin Bertram  wrote:
> >
> > I wonder if the newer version of Payara is now logging warnings about the
> > missing setters. The fact that they aren't there isn't new, but we can
> > certainly add them. Feel free to open a Jira.
> >
> > As for the MDBs not receiving messages, you are probably hitting
> > ARTEMIS-4188 [1].
> >
> >
> > Justin
> >
> > [1] https://issues.apache.org/jira/browse/ARTEMIS-4188
> >
> > On Wed, Apr 19, 2023 at 11:02 AM Marko Lazić  wrote:
> >
> > > Hello,
> > >
> > >
> > > The following code worked before with Payara 5.2022.2 1.8 jdk but now when
> > > i upgraded to 2.28.0 artemis and Payara 5.2022.5-jdk11 it has some 
> > > problems
> > >
> > > payara pre-boot.commands.asadmin file
> > >
> > > # Apache ActiveMQ Artemis
> > > deploy --type rar --name artemis-rar
> > > /opt/payara/deployments/artemis-rar-2.28.0.rar
> > > create-resource-adapter-config  --property
> > > ConnectorClassName='org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory':ConnectionParameters='host=broker;port=61616':UserName='artemis':Password='artemis'
> > > artemis-rar
> > > create-connector-connection-pool --raname artemis-rar
> > > --connectiondefinition
> > > org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactory --property
> > > UserName=artemis:Password=artemis  --ping true jms/ConnectionFactoryPool
> > > create-connector-resource --poolname jms/ConnectionFactoryPool
> > > jms/msgConnectionFactory
> > >
> > >
> > >
> > >
> > > Payara log
> > >
> > > [#|2023-04-19T15:52:44.487+|INFO|Payara
> > > 5.2022.5|fish.payara.boot.runtime.BootCommand|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564487;_LevelValue=800;|
> > >   Boot Command create-resource-adapter-config returned with result SUCCESS
> > > : PlainTextActionReporterSUCCESSNo monitoring data to report.
> > > |#]
> > > [#|2023-04-19T15:52:44.502+|WARNING|Payara 5.2022.5|javax.enterprise.
> > > resource.resourceadapter.com
> > > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564502;_LevelValue=900;|
> > >   RAR8000 : The method setPassword is not present in the class :
> > > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory|#]
> > > [#|2023-04-19T15:52:44.503+|WARNING|Payara 5.2022.5|javax.enterprise.
> > > resource.resourceadapter.com
> > > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564503;_LevelValue=900;|
> > >   RAR7097: No setter method present for the property password in the class
> > > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory|#]
> > > [#|2023-04-19T15:52:44.503+|WARNING|Payara 5.2022.5|javax.enterprise.
> > > resource.resourceadapter.com
> > > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564503;_LevelValue=900;|
> > >   RAR8000 : The method setUsername is not present in the class :
> > > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory|#]
> > > [#|2023-04-19T15:52:44.503+|WARNING|Payara 5.2022.5|javax.enterprise.
> > > resource.resourceadapter.com
> > > .sun.enterprise.connectors.util|_ThreadID=25;_ThreadName=RunLevelControllerThread-1681919558585;_TimeMillis=1681919564503;_LevelValue=900;|
> > >   RAR7097: No setter method present for the property username in the class
> > > org.apache.activemq.artemis.ra.ActiveMQRAMan

Re: Artemis activemq jms client all incompatible with artemis server

[Robbie Gemmell]

The artemis-jms-client-all module is really just intended to be used
standalone, and it shades things that artemis-server / commons / etc
do not (the server itself depends on the regular artemis-jms-client
etc). There are various concessions with it, which is why it is the
last thing mentioned in the [current] docs and comes with a warning.
Personally I would always recommend against using it (and have
previously even proposed deleting it).

I would never personally expect them to work together given the above,
and I dont believe there has ever been a single attempt running them
in the same classloader in the codebase, given all the actual tests
use artemis-jms-client and no tests use artemis-jms-client-all.

With your initial comments on the 'inconvenience' of
artemis-jms-client, I take it you are precluding build tooling that
can simply pick up the artemis-jms-client transitive dependencies for
you? The classpath details in the latest docs for the clients
'individual dependencies' is just generated, essentially by listing
the deps coming from having a maven dependency on artemis-jms-client.


Obligatory words of caution even though it seems like you know: 2.28.0
is the current release (with 2.29.0 imminent). There are no more
2.19.x releases coming. There are already 2 newer >8 Java LTS releases
and Java 21 becomes the next in about 4 months.

On Wed, 10 May 2023 at 17:37, PAS Filip  wrote:
>
> Hi Domenico,
>
> Nope both versions are identical.
>
> The broker I connect to remotely is running 2.28 and that connection works.
> All jars and classes of activemq in my project are version 2.19.1.
> It’s only an issue in my test suite when combining the two jars both of the 
> same version.
>
> Regards,
>
> Filip
>
> From: Domenico Francesco Bruscino 
> Sent: Wednesday, May 10, 2023 6:34 PM
> To: users@activemq.apache.org
> Subject: Re: Artemis activemq jms client all incompatible with artemis server
>
> Hi Filip, are you running the ActiveMQ Artemis jms client 2. 19. 1 and the 
> ActiveMQ Artemis server with a version different from 2. 19. 1 in the same 
> JVM? Regards, Domenico On Wed, 10 May 2023 at 18: 20, PAS Filip  sodexo. com. invalid>
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> ZjQcmQRYFpfptBannerEnd
>
> Hi Filip,
>
>
>
> are you running the ActiveMQ Artemis jms client 2.19.1 and the ActiveMQ
>
> Artemis server with a version different from 2.19.1 in the same JVM?
>
>
>
> Regards,
>
> Domenico
>
>
>
> On Wed, 10 May 2023 at 18:20, PAS Filip 
> mailto:filip@sodexo.com.invalid>>
>
> wrote:
>
>
>
> > Just a small follow-up, using artemis-jms-client instead of
>
> > artemis-jms-client-all seems to be working fine
>
> > There is are no duplicate shaded classes this way when combining it with
>
> > artemis-server.
>
> >
>
> > From: PAS Filip 
> > mailto:filip@sodexo.com.INVALID>>
>
> > Sent: Wednesday, May 10, 2023 3:14 PM
>
> > To: users@activemq.apache.org
>
> > Subject: Artemis activemq jms client all incompatible with artemis server
>
> >
>
> > Hello, I'm working on an application where we are migrating activemq to
>
> > artemis activemq. I'm running into an issue when trying to use the artemis
>
> > server and jms client all together on the same classpath. I'm using version
>
> > 2. 19. 1 of the artemis
>
> > ZjQcmQRYFpfptBannerStart
>
> > External sender
>
> > Check the sender and the content are safe before clicking links or open
>
> > attachments.
>
> > ZjQcmQRYFpfptBannerEnd
>
> >
>
> > Hello,
>
> >
>
> >
>
> >
>
> > I'm working on an application where we are migrating activemq to artemis
>
> > activemq.
>
> >
>
> >
>
> >
>
> > I'm running into an issue when trying to use the artemis server and jms
>
> > client all together on the same classpath.
>
> >
>
> >
>
> >
>
> > I'm using version 2.19.1 of the artemis activemq server since it's the
>
> > last version that's compatible with java 8.
>
> >
>
> > According to the docs I should use this version and it should be able to
>
> > connect fine to a remote activemq broker running java 11.
>
> >
>
> > That seems to work correctly however when running the integration test
>
> > suite I'm replacing the old activemq embedded broker with the one from
>
> > artemis activemq and am running into an issue of incompatibility.
>
> >
>
> >
>
> >
>
> > Our integration test suite uses the embedded broker so the artemis server
>
> > is added to the test classpath.
>
> >
>
> > When running the tests the embedded broker seems to start fine:
>
> >
>
> >
>
> >
>
> > [2023-05-10T14:21:58,942|INFO
>
> > |main|org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
>
> >
>
> > [2023-05-10T14:21:58,943|INFO
>
> > |main|org.apache.activemq.artemis.core.server] AMQ221001: Apache ActiveMQ
>
> > Artemis Message Broker version 2.19.1 [localhost,
>
> > nodeID=42455503-ef2d-11ed-8947-00090faa0001]
>
> >
>
> >
>
> >
>
> > However when connecting

Re: Artemis activemq jms client all incompatible with artemis server

[Robbie Gemmell]

I added a note to the docs for the next release about not being able to use
the -all clients in the same JVM as the broker:
https://github.com/apache/activemq-artemis/commit/7f4cd2ac56c383e20b72ec37b12fe6f71bebed1d

Artemis moved to requiring Java 11+ from 2.20.0 back in Dec 2021. The
2.19.1 release itself was mainly only done later due to an overlapping CVE
at that time, it is already over 15 months old now and there have been 10
new releases since. No more 2.19.x releases are coming.

On Wed, 10 May 2023, 19:13 PAS Filip,  wrote:

> Hi Robbie,
>
> Thanks for the feedback.
> It was not really an inconvenience to switch to the jms-client after all.
> I was able to use the transitive dependencies like you mentioned to get
> all I need.
> I didn’t get any versioning issues which is what I was worried about.
> That is why I actually liked the idea of using the shaded classes since it
> reduces the chance of conflicts with the libraries I’m using.
>
> The application I’m working on contains several frameworks that are EOL
> and incompatible with java 11.
> I can’t upgrade them and don’t have the time or budget to replace them.
> I hope you will keep providing critical bugfixes for the 2.19.x version
> and that the client remains compatible with the latest artemis servers.
>
> It would be good to provide some warning in the doc about the jms all
> client not being compatible with the embedded broker.
>
> Thanks for the feedback and confirming the issue.
>
> Regards,
>
> Filip
>
>
> From: Robbie Gemmell 
> Sent: Wednesday, May 10, 2023 8:01 PM
> To: users@activemq.apache.org
> Subject: Re: Artemis activemq jms client all incompatible with artemis
> server
>
> The artemis-jms-client-all module is really just intended to be used
> standalone, and it shades things that artemis-server / commons / etc do not
> (the server itself depends on the regular artemis-jms-client etc). There
> are various concessions
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> ZjQcmQRYFpfptBannerEnd
>
> The artemis-jms-client-all module is really just intended to be used
>
> standalone, and it shades things that artemis-server / commons / etc
>
> do not (the server itself depends on the regular artemis-jms-client
>
> etc). There are various concessions with it, which is why it is the
>
> last thing mentioned in the [current] docs and comes with a warning.
>
> Personally I would always recommend against using it (and have
>
> previously even proposed deleting it).
>
>
>
> I would never personally expect them to work together given the above,
>
> and I dont believe there has ever been a single attempt running them
>
> in the same classloader in the codebase, given all the actual tests
>
> use artemis-jms-client and no tests use artemis-jms-client-all.
>
>
>
> With your initial comments on the 'inconvenience' of
>
> artemis-jms-client, I take it you are precluding build tooling that
>
> can simply pick up the artemis-jms-client transitive dependencies for
>
> you? The classpath details in the latest docs for the clients
>
> 'individual dependencies' is just generated, essentially by listing
>
> the deps coming from having a maven dependency on artemis-jms-client.
>
>
>
>
>
> Obligatory words of caution even though it seems like you know: 2.28.0
>
> is the current release (with 2.29.0 imminent). There are no more
>
> 2.19.x releases coming. There are already 2 newer >8 Java LTS releases
>
> and Java 21 becomes the next in about 4 months.
>
>
>
> On Wed, 10 May 2023 at 17:37, PAS Filip  <mailto:filip@sodexo.com.invalid>> wrote:
>
> >
>
> > Hi Domenico,
>
> >
>
> > Nope both versions are identical.
>
> >
>
> > The broker I connect to remotely is running 2.28 and that connection
> works.
>
> > All jars and classes of activemq in my project are version 2.19.1.
>
> > It’s only an issue in my test suite when combining the two jars both of
> the same version.
>
> >
>
> > Regards,
>
> >
>
> > Filip
>
> >
>
> > From: Domenico Francesco Bruscino  bruscin...@gmail.com>>
>
> > Sent: Wednesday, May 10, 2023 6:34 PM
>
> > To: users@activemq.apache.org<mailto:users@activemq.apache.org>
>
> > Subject: Re: Artemis activemq jms client all incompatible with artemis
> server
>
> >
>
> > Hi Filip, are you running the ActiveMQ Artemis jms client 2. 19. 1 and
> the ActiveMQ Artemis server with a version different from 2. 19. 1 in the
> same JVM? Regards, Domenico On Wed, 10 May 2

Re: No Journal logging

[Robbie Gemmell]

Those files are specifically for the 'identified messages' with IDs,
as contained in them. You will only see anything for them if a
situation arises to emit such a log message. That logger config is
there to ensure those remain enabled by default even if adjusting with
the wider config.

If you are looking for more general implementation-detail style
logging about the journal, perhaps try hierarchies like
org.apache.activemq.artemis.core.journal.impl and
org.apache.activemq.artemis.core.persistence.impl.journal or others
around there.

On Thu, 18 May 2023 at 15:24, Doug Whitfield
 wrote:
>
> I found the path at 
> https://github.com/apache/activemq-artemis/tree/main/artemis-journal/src/main/java/org/apache/activemq/artemis/journal
>  but question remains, why are we logging nothing?
>
> From: Doug Whitfield 
> Date: Thursday, 18 May 2023 at 08:57
> To: users@activemq.apache.org 
> Subject: No Journal logging
> We have the below config. I see at 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2F&data=05%7C01%7Cdwhitfield%40perforce.com%7C4d4fda7b7f0e41d5a25b08db57a7d62d%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638200150613335659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ma000zE%2FtxIBoyugKkUsu%2BoeG4gsYFwWltTNPDiX2Qs%3D&reserved=0
>  that this is correct. I can see at 
> https://github.com/apache/activemq-artemis/tree/main/artemis-server/src/main/java/org/apache/activemq/artemis/core
> that org.apache.activemq.artemis.core.server exists. However, I don’t see see 
> a journal, jms, or utils directory.
>
> How do we log the journal?
>
> # Log4J 2 configuration
>
>
> # Monitor config file every X seconds for updates
>
> monitorInterval = 5
>
>
> rootLogger = INFO, console, log_file
>
>
> logger.activemq.name=org.apache.activemq
>
> logger.activemq.level=INFO
>
>
> logger.artemis_server.name=org.apache.activemq.artemis.core.server
>
> logger.artemis_server.level=DEBUG
>
>
> logger.artemis_journal.name=org.apache.activemq.artemis.journal
>
> logger.artemis_journal.level=DEBUG
>
>
> logger.artemis_jms.name=org.apache.activemq.artemis.jms
>
> logger.artemis_jms.level=DEBUG
>
>
> logger.artemis_utils.name=org.apache.activemq.artemis.utils
>
> logger.artemis_utils.level=INFO
>
>
> # CriticalAnalyzer: If you have issues with the CriticalAnalyzer, setting 
> this to TRACE would give
>
> # you extra troubleshooting info, but do not use TRACE regularly as it would 
> incur extra CPU usage.
>
> logger.critical_analyzer.name=org.apache.activemq.artemis.utils.critical
>
> logger.critical_analyzer.level=INFO
>
>
> # Audit loggers: to enable change levels from OFF to INFO
>
> logger.audit_base = OFF, audit_log_file
>
> logger.audit_base.name = org.apache.activemq.audit.base
>
> logger.audit_base.additivity = false
>
>
> logger.audit_resource = OFF, audit_log_file
>
> logger.audit_resource.name = org.apache.activemq.audit.resource
>
> logger.audit_resource.additivity = false
>
>
> logger.audit_message = INFO, audit_log_file
>
> logger.audit_message.name = org.apache.activemq.audit.message
>
> logger.audit_message.additivity = false
>
>
> # Jetty logger levels
>
> logger.jetty.name=org.eclipse.jetty
>
> logger.jetty.level=WARN
>
>
> # Quorum related logger levels
>
> logger.curator.name=org.apache.curator
>
> logger.curator.level=WARN
>
> logger.zookeeper.name=org.apache.zookeeper
>
> logger.zookeeper.level=ERROR
>
>
>
> # Console appender
>
> appender.console.type=Console
>
> appender.console.name=console
>
> appender.console.layout.type=PatternLayout
>
> appender.console.layout.pattern=%d %-5level [%logger] %msg%n
>
>
> # Log file appender
>
> appender.log_file.type = RollingFile
>
> appender.log_file.name = log_file
>
> appender.log_file.fileName = ${sys:artemis.instance}/log/artemis.log
>
> appender.log_file.filePattern = 
> ${sys:artemis.instance}/log/artemis.log.%d{-MM-dd}
>
> appender.log_file.layout.type = PatternLayout
>
> appender.log_file.layout.pattern = %d %-5level [%logger] %msg%n
>
> appender.log_file.policies.type = Policies
>
> appender.log_file.policies.cron.type = CronTriggeringPolicy
>
> appender.log_file.policies.cron.schedule = 0 0 0 * * ?
>
> appender.log_file.policies.cron.evaluateOnStartup = true
>
> # Audit log file appender
>
> appender.audit_log_file.type = RollingFile
>
> appender.audit_log_file.name = audit_log_file
>
> appender.audit_log_file.fileName = ${sys:artemis.instance}/log/audit.log
>
> appender.audit_log_file.filePattern = 
> ${sys:artemis.instance}/log/audit.log.%d{-MM-dd}
>
> appender.audit_log_file.layout.type = PatternLayout
>
> appender.audit_log_file.layout.pattern = %d [AUDIT](%t) %msg%n
>
> appender.audit_log_file.policies.type = Policies
>
> appender.audit_log_file.policies.cron.type = CronTriggeringPolicy
>
> appender.audit_log_file.policies.cron.schedule 

Re: No Journal logging

[Robbie Gemmell]

I'd guess the perf command sends non-persistent messages by default,
and so you arent really using the journal there and thus wont see
journal logging.

I see a load of logging if I enable TRACE on e.g
org.apache.activemq.artemis.core.journal.impl and send persistent
messages.

On Thu, 18 May 2023 at 17:35, Doug Whitfield
 wrote:
>
> Thanks Robbie.
>
> I am still a bit confused. Maybe some background would be helpful. Currently, 
> I am using the following command:
> artemis perf client --message-count 100
>
> I would expect to see something moving to the journal, and I would expect to 
> see that logged. Even setting org.apache.activemq.artemis.core.journal.impl 
> and org.apache.activemq.artemis.core.persistence.impl.journal to TRACE I 
> don’t see anything different.
>
> Originally, we were troubleshooting a performance issue, and wanted to see 
> NIO vs ASYNCIO. We have gotten to a point though were we do not believe the 
> issue is storage and rather it is flowControl. I think we probably have the 
> logging we need for that. However, in the future, if we needed to 
> troubleshoot the journal, and get higher logging, how would we do that? I 
> think you are saying we just aren’t seeing it because we aren’t hitting the 
> narrow set of issues that are actually logged, but I want to be sure that is 
> the correct interpretation.
>
>
> From: Robbie Gemmell 
> Date: Thursday, 18 May 2023 at 10:13
> To: users@activemq.apache.org 
> Subject: Re: No Journal logging
> Those files are specifically for the 'identified messages' with IDs,
> as contained in them. You will only see anything for them if a
> situation arises to emit such a log message. That logger config is
> there to ensure those remain enabled by default even if adjusting with
> the wider config.
>
> If you are looking for more general implementation-detail style
> logging about the journal, perhaps try hierarchies like
> org.apache.activemq.artemis.core.journal.impl and
> org.apache.activemq.artemis.core.persistence.impl.journal or others
> around there.
>
> On Thu, 18 May 2023 at 15:24, Doug Whitfield
>  wrote:
> >
> > I found the path at 
> > https://github.com/apache/activemq-artemis/tree/main/artemis-journal/src/main/java/org/apache/activemq/artemis/journal
> >  but question remains, why are we logging nothing?
> >
> > From: Doug Whitfield 
> > Date: Thursday, 18 May 2023 at 08:57
> > To: users@activemq.apache.org 
> > Subject: No Journal logging
> > We have the below config. I see at 
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2F&data=05%7C01%7Cdwhitfield%40perforce.com%7Cb1d8e30c8ccb4fbe098708db57b277a0%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638200196260738606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HpKb%2F3cmCYih4GWYK4FGuqQaWJUbCXO4T%2FbVhrHVo%2Fc%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2F&data=05%7C01%7Cdwhitfield%40perforce.com%7Cb1d8e30c8ccb4fbe098708db57b277a0%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638200196260738606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HpKb%2F3cmCYih4GWYK4FGuqQaWJUbCXO4T%2FbVhrHVo%2Fc%3D&reserved=0><https://activemq.apache.org/components/artemis/documentation/>
> >  that this is correct. I can see at 
> > https://github.com/apache/activemq-artemis/tree/main/artemis-server/src/main/java/org/apache/activemq/artemis/core
> > that org.apache.activemq.artemis.core.server exists. However, I don’t see 
> > see a journal, jms, or utils directory.
> >
> > How do we log the journal?
> >
> > # Log4J 2 configuration
> >
> >
> > # Monitor config file every X seconds for updates
> >
> > monitorInterval = 5
> >
> >
> > rootLogger = INFO, console, log_file
> >
> >
> > logger.activemq.name=org.apache.activemq
> >
> > logger.activemq.level=INFO
> >
> >
> > logger.artemis_server.name=org.apache.activemq.artemis.core.server
> >
> > logger.artemis_server.level=DEBUG
> >
> >
> > logger.artemis_journal.name=org.apache.activemq.artemis.journal
> >
> > logger.artemis_journal.level=DEBUG
> >
> >
> > logger.artemis_jms.name=org.apache.activemq.artemis.jms
> >
> > logger.artemis_jms.level=DEBUG
> >
> >
> > logger.artemis_utils.name=org.apache.activemq.artemis.utils
> >
> > logger.artemis_utils.level=INFO
> >
> >

Re: No Journal logging

[Robbie Gemmell]

The value in the default log4j2.properties file and which is reflected
in the doc, is aimed at the more general/operational 'identified
messages with IDs' about the journal. Those do indeed live under
org.apache.activemq.artemis.journal, as shown when you linked to them
earlier.

The journals implementation classes and related implementation-detail
loggers exist separately, and those classes have .core. in their
hierarchy (either historic, or more probably just meaning 'core' in
the central/main sense rather than anything to do with e.g the CORE
protocol...I used AMQP for example when I verified that TRACE for
org.apache.activemq.artemis.core.journal.impl resulted in journal
logging).

On Fri, 19 May 2023 at 15:03, Doug Whitfield
 wrote:
>
> Thanks Robbie!
>
> I see these now in TRACE:
> org.apache.activemq.artemis.core.journal.impl.JournalImpl
>
> But the documentation says org.apache.activemq.artemis.journal
>
> Is the documentation wrong or does it just not apply to CORE? It is very 
> confusing, either way.
>
> From: Robbie Gemmell 
> Date: Friday, 19 May 2023 at 06:15
> To: users@activemq.apache.org 
> Subject: Re: No Journal logging
> I'd guess the perf command sends non-persistent messages by default,
> and so you arent really using the journal there and thus wont see
> journal logging.
>
> I see a load of logging if I enable TRACE on e.g
> org.apache.activemq.artemis.core.journal.impl and send persistent
> messages.
>
> On Thu, 18 May 2023 at 17:35, Doug Whitfield
>  wrote:
> >
> > Thanks Robbie.
> >
> > I am still a bit confused. Maybe some background would be helpful. 
> > Currently, I am using the following command:
> > artemis perf client --message-count 100
> >
> > I would expect to see something moving to the journal, and I would expect 
> > to see that logged. Even setting 
> > org.apache.activemq.artemis.core.journal.impl and 
> > org.apache.activemq.artemis.core.persistence.impl.journal to TRACE I don’t 
> > see anything different.
> >
> > Originally, we were troubleshooting a performance issue, and wanted to see 
> > NIO vs ASYNCIO. We have gotten to a point though were we do not believe the 
> > issue is storage and rather it is flowControl. I think we probably have the 
> > logging we need for that. However, in the future, if we needed to 
> > troubleshoot the journal, and get higher logging, how would we do that? I 
> > think you are saying we just aren’t seeing it because we aren’t hitting the 
> > narrow set of issues that are actually logged, but I want to be sure that 
> > is the correct interpretation.
> >
> >
> > From: Robbie Gemmell 
> > Date: Thursday, 18 May 2023 at 10:13
> > To: users@activemq.apache.org 
> > Subject: Re: No Journal logging
> > Those files are specifically for the 'identified messages' with IDs,
> > as contained in them. You will only see anything for them if a
> > situation arises to emit such a log message. That logger config is
> > there to ensure those remain enabled by default even if adjusting with
> > the wider config.
> >
> > If you are looking for more general implementation-detail style
> > logging about the journal, perhaps try hierarchies like
> > org.apache.activemq.artemis.core.journal.impl and
> > org.apache.activemq.artemis.core.persistence.impl.journal or others
> > around there.
> >
> > On Thu, 18 May 2023 at 15:24, Doug Whitfield
> >  wrote:
> > >
> > > I found the path at 
> > > https://github.com/apache/activemq-artemis/tree/main/artemis-journal/src/main/java/org/apache/activemq/artemis/journal
> > >  but question remains, why are we logging nothing?
> > >
> > > From: Doug Whitfield 
> > > Date: Thursday, 18 May 2023 at 08:57
> > > To: users@activemq.apache.org 
> > > Subject: No Journal logging
> > > We have the below config. I see at 
> > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2F&data=05%7C01%7Cdwhitfield%40perforce.com%7C562785de2662461985c008db585a4700%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638200917014959800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=L3vSAuP927e1%2Fk9i6AgjLkM8Krt4iQ4%2Fac%2BaqLqiR8E%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2F&data=05%7C01%7Cdwhitfield%40perforce.com%7C562785de2662461985c008db585a4700%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C

Re: Artemis docker container readme wrong or defective?

[Robbie Gemmell]

Also, rather than the repo folks can get the latest released script
etc bits from the source release archive at
https://activemq.apache.org/components/artemis/download/

On Tue, 23 May 2023 at 06:39, Vilius Šumskas  wrote:
>
> Hi,
>
> you don't need whole repo, artemis-docker folder is enough.
>
> Regarding your docker error, you have to have Docker installed in order to 
> build the image. I suspect you are running bash script from WSL, but 
> environment doesn't have docker installed _inside_ WSL.
>
> --
> Vilius
>
> -Original Message-
> From: Pablo Krause 
> Sent: Tuesday, May 23, 2023 6:35 AM
> To: users@activemq.apache.org
> Subject: Re: Artemis docker container readme wrong or defective?
>
> Thanks for the fast response and help.
>
> First, nowhere in the doc does it say I must clone the whole repo. I
> (erroneously) supposed that by using the --from-release option It would 
> download the needed binary.
> Second, I was testing from bash Windows terminal I tried using Windows 
> Subsystem for Linux, and the prepare-docker.sh scrpts works fine, but the 
> docker build fails miserably with "lstat
> docker: no such file or directory".
> I'm guessing it doesn't work in WSL?
>
> I guess I'll build my own image as I did with the older activemq instead of 
> trying to make this work. It should be incredibly easy.
> Shouldn't need to clone the repo.
>
> On Sun, May 21, 2023 at 10:42 PM Domenico Francesco Bruscino 
>  wrote:
> >
> > Hi Pablo,
> >
> > it works for me, maybe your local repo is damaged or your current
> > directory is not `artemis-docker` when you run prepare-docker.sh.
> > Could you try the following commands:
> >
> > git clone g...@github.com:apache/activemq-artemis.git
> > /tmp/activemq-artemis cd /tmp/activemq-artemis/artemis-docker/
> > ./prepare-docker.sh --from-release --artemis-version 2.28.0
> >
> > Regards,
> > Domenico
> >
> > On Sun, 21 May 2023 at 06:03, Pablo Krause  wrote:
> >
> > > I'm trying to create a docker container for artemis using this
> > > official
> > > readme:
> > > https://github.com/apache/activemq-artemis/tree/main/artemis-docker
> > >
> > > Either the doc is wrong/incomplete, the script is defective, or I am
> > > an idiot.
> > > In either case, help would be appreciated.
> > >
> > > In particular I am running this:
> > >
> > > ./prepare-docker.sh --from-release --artemis-version 2.28.0
> > >
> > > It successfully downloads stuff, and then it fails with "cp: cannot
> > > stat './Dockerfile-*': No such file or directory"
> > >
> > > Thanks.
> > >
>
>
>
> --
>
>
> Pablo Krause
> Tensegrity Services
> +52 (55) 8000 6750
> www.tenser.mx

Re: PGP signature and SHA512 checksum do not match download

[Robbie Gemmell]

The signatures and checksums do validate ok here.

The main archive links are to a mirror-selector script, be sure to
click through to get the page with actual download link, rather than
e.g downloading the page HTML as I guess you might have.

If you aren't using the client already you might want to look at
alternative options for new developments, as it isnt really active
these days: https://github.com/apache/activemq-cpp/


On Fri, 9 Jun 2023 at 00:15, Wall, Treven P.  wrote:
>
> Hello,
>
> I'm attempting to use version 3.9.5 of your CPP library, but the signature 
> and checksum of your Unix versions don't match the downloaded files here: 
> https://activemq.apache.org/components/cms/download/395-release
>
> Please fix this so these files can be trusted.
>
> Thank you!
> T Wall

Re: Artemis client can't connect to Artemis server

[Robbie Gemmell]

The "Configuration %s: url is not set and devservices is activated.
This is a bug. Please report it."  IllegalStateException definitely
seems like something is broken in quarkus-artemis-jms config handling,
and worth reporting to them.

Actually, I now see you already have as:
https://github.com/quarkiverse/quarkus-artemis/issues/241


On Thu, 29 Jun 2023 at 19:08, David Hoffer  wrote:
>
> Hi,
>
> We have a Quarkus app where we embed an Artemis server, we were using
> 2.27.1.  We were connecting to it via quarkus-artemis-jms 1.0.3 which I see
> now is very old.  This stopped working and strangely it stopped working
> when it tried to create the activemq working directories.
>
> I have tried upgrading to quarkus-artemis-jms 2.1.1 but strangely that
> version can't read our quarkus properties correctly.  It reads the wrong
> value for build time is devervices enabled and wrong value for url
> setting.  Can't figure that one out.  So we get this error:
>
> new IllegalStateException(String.format(
> "Configuration %s: url is not set and devservices is
> activated. This is a bug. Please report it.", name));
>
> So taking a step back here I'm thinking we don't have the correct
> dependencies in our build.  Can you point me to the correct way to include
> both the artemis server and the artemis client jars?  E.g. is there a BOM
> for these?
>
> We are using Quarkus 2.16.7
> JDK 11
> We would prefer to use the latest known stable versions of Artemis server
> and client components, but most important is that they work together
> properly.
>
> Thanks,
> -David
>
> P.S. Here is the error log when it fails to generate the working
> folders/files.  Note the broker.xml file does exist, no idea why that shows
> as a warning.
>
> 14:07:17,414 dhoffe-bstaq-pc ./target/app-runner.jar[10576] WARN
>  [org.apa.act.art.cor.server] (main) AMQ19: File
> file:\C:\projects\app\target\app-runner.jar!\broker.xml does not exist
> 2023-06-26 14:07:17,426 dhoffe-bstaq-pc ./target/app-runner.jar[10576] INFO
>  [org.apa.act.art.cor.server] (main) AMQ221034: Waiting indefinitely to
> obtain live lock
> 2023-06-26 14:07:17,426 dhoffe-bstaq-pc ./target/app-runner.jar[10576] INFO
>  [org.apa.act.art.cor.server] (main) AMQ221035: Live Server Obtained live
> lock
> 2023-06-26 14:07:17,434 dhoffe-bstaq-pc ./target/app-runner.jar[10576] WARN
>  [org.apa.act.art.journal] (main) AMQ142018: Temporary files were left
> unattended after a crash on journal directory, deleting invalid files now
> 2023-06-26 14:07:17,434 dhoffe-bstaq-pc ./target/app-runner.jar[10576] WARN
>  [org.apa.act.art.journal] (main) AMQ142019: Deleting orphaned file
> activemq-bindings-4.bindings.tmp
> 2023-06-26 14:07:17,492 dhoffe-bstaq-pc ./target/app-runner.jar[10576]
> ERROR [org.apa.act.art.cor.server] (main) AMQ224000: Failure in
> initialisation: java.lang.IndexOutOfBoundsException
> at java.base/java.nio.Buffer.checkIndex(Buffer.java:687)
> at java.base/java.nio.DirectByteBuffer.put(DirectByteBuffer.java:344)
> at
> org.apache.activemq.artemis.utils.ByteUtil.uncheckedZeros(ByteUtil.java:512)
> at org.apache.activemq.artemis.utils.ByteUtil.zeros(ByteUtil.java:494)
> at
> org.apache.activemq.artemis.core.io.util.ThreadLocalByteBufferPool.borrow(ThreadLocalByteBufferPool.java:47)
> at
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.newBuffer(NIOSequentialFileFactory.java:150)
> at
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.newBuffer(NIOSequentialFileFactory.java:142)
> at
> org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.fill(NIOSequentialFile.java:170)
> at
> org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile0(JournalFilesRepository.java:655)
> at
> org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile(JournalFilesRepository.java:611)
> at
> org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.ensureMinFiles(JournalFilesRepository.java:220)
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.setUpCurrentFile(JournalImpl.java:3454)
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:2288)
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:2340)
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1669)
> at org.apache.activemq.artemis.core.journal.Journal.load(Journal.java:278)
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadBindingJournal(AbstractJournalStorageManager.java:1515)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3643)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3324)
> at
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerIm

Re: Smallrye reactive messaging's emitter does not NACK messages sent to Artemis broker

[Robbie Gemmell]

The brokers auto-creation handling defaults to creating 'multicast'
addresses+queues unless requested otherwise by either the connecting
producer specifying what it wants, or by updating the brokers default
address configuration for that address. That is, it gives topic-like
pub-sub behaviour if not asked otherwise. You dont seem to create any
consumers/subscriptions. If so the message was presumably received,
accepted, and discarded as there were no subscriptions for it.
"Couldn't find any bindings for address=random-address "is saying
there were no [subscription-backing] queues bound to that address to
put the message on.

It sounds like you want 'queue' like behaviour instead, i.e create
queue of that name if needed and put the message on it for later. You
can either configure the address settings to get this 'anycast'
behaviour (i.e queue like behaviour) by default upon auto-creation for
clients not requesting specific behaviour, or you ensure your client
requests the behaviour it actually wants.

For the former, see the broker documentation:
https://activemq.apache.org/components/artemis/documentation/
E.g perhaps 
https://activemq.apache.org/components/artemis/documentation/latest/address-model.html
and 
https://activemq.apache.org/components/artemis/documentation/latest/address-settings.html

For the latter, looks like you can use the 'capabilities' config for
smallrye-reactive-messaging-amqp to configure what you want. You might
try "queue" or "topic" depending on what behaviour you want to
request:
https://smallrye.io/smallrye-reactive-messaging/4.7.0/amqp/sending-amqp-messages/#configuration-reference

Alternatively still, you could pre-create the addresses and queues you
want to use by specifying them in the broker config to pre-create
them.

On Fri, 7 Jul 2023 at 13:22, Nicolaescu, Eugeniu
 wrote:
>
> I'm facing an issue when using the AMQP connector and an Apache Artemis
> broker and I'm not sure if it's an error on my part somehow or one of the
> two doesn't handle this case properly
>
> Problem: I send a message to the broker using an emitter, if the target
> address does not have a queue the broker will log the error:
> Couldn't find any bindings for address=random-address on
> message=AMQPStandardMessage..
> The message is never sent to any queue and is lost, but the emitter does
> not NACK the message nor it reports any error on the quarkus CLI
>
>
>
> How to reproduce:
>
> Start the apache artemis container:
> ```
> docker pull quay.io/artemiscloud/activemq-artemis-broker:artemis.2.27.1
> docker run -d -p 8161:8161 -p 61616:61616 -e AMQ_USER=artemis -e
> AMQ_PASSWORD=artemis -e AMQ_EXTRA_ARGS: "--host 0.0.0.0 --http-host 0.0.0.0
> --relax-jolokia" quay.io/artemiscloud/activemq-artemis-broker:artemis.2.27.1
> ```
>
> The console is accessible at localhost:8161 with credentials artemis/artemis
> You should also go to JMX -> org.apache.logging.log4j2 ->
> org.apache.activemq logger and set the log level to DEBUG
>
>
> Run the message producer:
> clone https://github.com/quarkusio/quarkus-quickstarts
> cd  .\amqp-quickstart
> update the properties file
> .\amqp-quickstart\amqp-quickstart-producer\src\main\resources\application.properties
> by adding these properties:
> ```
> amqp-host=localhost
> amqp-port=61616
> amqp-username=artemis
> amqp-password=artemis
>
> mp.messaging.outgoing.quote-requests.connector=smallrye-amqp
> mp.messaging.outgoing.quote-requests.address=random-address
> mp.messaging.outgoing.quote-requests.durable=true
> ```
>
> Run the producer:
> `mvn -f amqp-quickstart-producer quarkus:dev`
>
> Now you can send a message to the artemis broker by sending a post request
> to http://localhost:8080/quotes/request
>
> You could also update the QuotesResource.java class by checking the emitter
> result like this:
> ```
> CompletionStage completionStage =
> quoteRequestEmitter.send(uuid.toString()); // <2>
> completionStage.toCompletableFuture().join();
> ```
>
> but it's the same thing, no error is reported

Re: Artemis Compatible version Spring Boot Starter Artemis

[Robbie Gemmell]

Artemis releases after 2.19.1 require Java 11+

On Tue, 11 Jul 2023 at 13:49, Shivang Modi  wrote:
>
> Hi Team,
>
>
>
> I am upgrading my Spring Boot project from ActiveMQ to Artemis. While
> upgrading, if I use Artemis 2.19 version, connection happens successfully
> and if I use Artemis 2.28 version, connection didn’t happen.
>
>
>
> I have spring boot start actuator jar with 2.7.13 version and java 8. What
> is compatible ActiveMQ Artemis with Springboot starter Artemis client.
>
>
>
> Thanks,
>
> Shivang.
>
> --
> *This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this e-mail
> or its contents to any other person and any such actions maybe unlawful*.
> This e-mail may contain viruses. Provenir has taken every reasonable
> precaution to minimize this risk, but is not liable for any damage you may
> sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Provenir reserves
> the right to monitor and review the content of all messages sent to or from
> this e-mail address. Messages sent to or from this e-mail address may be
> stored on the Provenir e-mail system.

Re: Unexpected behaviour with virtual topics

[Robbie Gemmell]

I believe the virtualTopicConsumerWildcards stuff only applies for
Openwire protocol clients (i.e ActiveMQ 5.x), as used in the example
you referenced.

Your description and log snippets note you are trying to use that with
the Artemis Core JMS client instead, meaning those bits just dont
apply. You should use the JMS 2 APIs for creating shared subscriptions
to create+consume from new shared subscription backing queues, or
alternatively you could use an FQQN address with a Topic subscriber.

(Obligatory note that 2.19.1 is already an older release at this
point, and there won't be any more 2.19.x releases. Aside, the next
JDK LTS, 21, is due for RC1 next week...previously with JDK17, RC1
became the GA).

On Tue, 1 Aug 2023 at 21:12, PAS Filip  wrote:
>
> Hello,
>
> I'm running into a strange issue I cannot explain and was hoping someone 
> could shed some light on the issue.
>
> I'm running an artemis broker 2.28.0 using the artemis jms client 2.19.1 (the 
> latest java 8 compatible client, my client must be java 8 unfortunately).
>
> I've created a broker using all standard settings and copied the broker 
> configuration from the openwire virtual topic example, specifically the 
> acceptor and the topic configuration:
>
>  name="artemis">tcp://0.0.0.0:61616?virtualTopicConsumerWildcards=Consumer.*.%3E%3B2
>
> 
>  
>
> 
> 
>
> If I copy the code from the virtual topic example into my project and run it 
> the test fails.
> The message sent to VirtualTopic.Orders  is not delivered to the consumer of 
> the Consumer.A.VirtualTopic.Orders destination.
> The destination Consumer.A.VirtualTopic.Orders is created as a queue and is 
> visible as a separate address and not visible under the topic in the console.
> In the log I found this message:
>
> DEBUG o.a.activemq.artemis.core.client - The queue 
> Consumer.A.VirtualTopic.Orders was created automatically.
>
> To make the example work I changed the configuration in the broker.xml to:
>
> 
> 
>  />
> 
> 
>
> The log statement then disappears, and the behaviour is as expected.
>
> I'm trying to figure out where this difference in behaviour comes from.
> Is there something in the maven plugin used to bootstrap the broker for the 
> test that does some additional configuration that would change this behaviour?
>
> In my use case we need to get this configuration working with the  
>  tag so we can add additional queues that will receive the 
> messages from the topic
> Without having to predefine them all in the configuration.
>
>
> Anyone have any ideas or suggestions that would greatly be appreciated.
>
> Regards,
>
> Filip
>
>

Re: Unexpected behaviour with virtual topics

[Robbie Gemmell]

 static void main(final String[] args) throws Exception {
>
> Connection connection = null;
>
> try {
>
>
>
> ConnectionFactory cf = new ActiveMQConnectionFactory();
>
>
>
> connection = cf.createConnection();
>
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
>
>
>
> //create consumer on queue that is used by the Virtual Topic
>
> Queue queue = 
> session.createQueue("VirtualTopic.Orders::Consumer.A.VirtualTopic.Orders");
>
> MessageConsumer messageConsumer = session.createConsumer(queue);
>
> connection.start();
>
>
>
> //send message to virtual topic
>
> Topic topic = session.createTopic("VirtualTopic.Orders");
>
> MessageProducer producer = session.createProducer(topic);
>
> TextMessage message = session.createTextMessage("This is a text 
> message");
>
> producer.send(message);
>
>
>
> System.out.println("Sent message with ID: " + 
> message.getJMSMessageID() + " to Topic: " + topic.getTopicName());
>
>
>
> //consume the message from the backing queue
>
> TextMessage messageReceived = (TextMessage) 
> messageConsumer.receive(5000);
>
>
>
> if (messageReceived != null) {
>
> System.out.println("Received message with ID: " + 
> messageReceived.getJMSMessageID() + " from Queue: " + queue.getQueueName());
>
> } else {
>
> //unexpected outcome
>
> throw new RuntimeException("EXAMPLE FAILED - No message 
> received from Queue: " + queue.getQueueName());
>
> }
>
> } finally {
>
> if (connection != null) {
>
> connection.close();
>
> }
>
> }
>
> }
>
>
>
> Thanks in advance for any help you can provide.
>
>
>
> Regards,
>
>
>
> Filip
>
>
>
> From: Robbie Gemmell 
> mailto:robbie.gemm...@gmail.com>>
>
> Sent: Wednesday, August 2, 2023 1:36 PM
>
> To: users@activemq.apache.org<mailto:users@activemq.apache.org>
>
> Subject: Re: Unexpected behaviour with virtual topics
>
>
>
> I believe the virtualTopicConsumerWildcards stuff only applies for Openwire 
> protocol clients (i. e ActiveMQ 5. x), as used in the example you referenced. 
> Your description and log snippets note you are trying to use that with the 
> Artemis Core
>
> ZjQcmQRYFpfptBannerStart
>
> External sender
>
> Check the sender and the content are safe before clicking links or open 
> attachments.
>
> ZjQcmQRYFpfptBannerEnd
>
>
>
> I believe the virtualTopicConsumerWildcards stuff only applies for
>
>
>
> Openwire protocol clients (i.e ActiveMQ 5.x), as used in the example
>
>
>
> you referenced.
>
>
>
>
>
>
>
> Your description and log snippets note you are trying to use that with
>
>
>
> the Artemis Core JMS client instead, meaning those bits just dont
>
>
>
> apply. You should use the JMS 2 APIs for creating shared subscriptions
>
>
>
> to create+consume from new shared subscription backing queues, or
>
>
>
> alternatively you could use an FQQN address with a Topic subscriber.
>
>
>
>
>
>
>
> (Obligatory note that 2.19.1 is already an older release at this
>
>
>
> point, and there won't be any more 2.19.x releases. Aside, the next
>
>
>
> JDK LTS, 21, is due for RC1 next week...previously with JDK17, RC1
>
>
>
> became the GA).
>
>
>
>
>
>
>
> On Tue, 1 Aug 2023 at 21:12, PAS Filip 
> mailto:filip@sodexo.com.invalid<mailto:filip@sodexo.com.invalid%3cmailto:filip@sodexo.com.invalid>>>
>  wrote:
>
>
>
> >
>
>
>
> > Hello,
>
>
>
> >
>
>
>
> > I'm running into a strange issue I cannot explain and was hoping someone 
> > could shed some light on the issue.
>
>
>
> >
>
>
>
> > I'm running an artemis broker 2.28.0 using the artemis jms client 2.19.1 
> > (the latest java 8 compatible client, my client must be java 8 
> > unfortunately).
>
>
>
> >
>
>
>
> > I've created a broker using all standard settings and copied the broker 
> > configuration from the openwire virtual topic example, specifically the 
> > acceptor and the topic configuration:
>
>
>
> >
>
>
>

Re: Reg activemq jakarta namespace support

[Robbie Gemmell]

As Justin said, see https://activemq.apache.org/jms2. The 5.18.x zip
distribution is only javax.jms API package based, nothing will change
for the zip until 5.19.x adds jakarta.jms API package support for the
wider codebase, something which is still being worked on (e.g
https://github.com/apache/activemq/pull/996). The transitional
activemq-client-jakarta module added in 5.18.x which is jakarta.jms
API package based, is a separate module available from Maven Central.
Note that per the https://activemq.apache.org/jms2 page it can't be
used embedded in the same JVM as the broker (or javax based
activemq-client). Note also you should avoid the 5.18.0
activemq-client-jakarta as it was actually broken, be sure to use
5.18.1 or the current 5.18.2.

On Mon, 7 Aug 2023 at 18:55, Justin Bertram  wrote:
>
> Which exact client library are you using?
>
> ActiveMQ 5.18.x introduced the activemq-client-jakarta module which is
> separate from the normal JMS client. You can find the versions here [1].
>
> That said, the client is not "fully compatible" as certain methods have not
> yet been implemented. See this page [2] for more details.
>
>
> Justin
>
> [1]
> https://central.sonatype.com/artifact/org.apache.activemq/activemq-client-jakarta/5.18.0/versions
> [2] https://activemq.apache.org/jms2
>
> On Mon, Aug 7, 2023 at 12:43 PM Jayesh Vaishnav 
> wrote:
>
> > Hello,
> >
> > I am currently migrating to activemq5.18 which has support for jakarta
> > namespace, however there are still references to old javax packages, I am
> > getting ClassNotFoundException for javax.jms.JMSException, the right
> > package should be jakarta.jms
> >
> > In the zip distribution, I see jakarta-2.X is used for which the underlying
> > package is still javax. Rather to fully support jakarta namespace, we
> > should move to jakarta 3.x
> >
> > Seems we are not fully compliant yet. can we make changes to fix this
> >
> > THanks
> >

Re: building docker image following the guide - not working for me - I'm sure I'm missing something

[Robbie Gemmell]

Recent JDK changes seemed to break something in the version of Karaf
that the build was using. Updating to a newer version resolved things:
https://issues.apache.org/jira/browse/ARTEMIS-4373
https://github.com/apache/activemq-artemis/commit/c81e079122

On Sat, 26 Aug 2023 at 15:49, Mike Williams  wrote:
>
>
> As a side note...
> rebuild-snapshots.sh worked for me on tag 2.17.0 src tgz (the initial target 
> version for my k8s deployment) and main (2.31.0) but failed on tag 2.30.0 src 
> tgz
> This is off topic, just mentioning as an observation from my local system - 
> mvn dependency issue perhaps?:
> "[ERROR] Failed to execute goal 
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify (verify) on project 
> artemis-features: Execution verify of goal 
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify failed: A required 
> class was missing while executing 
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify: 
> org/apache/karaf/features/internal/service/Deployer$DeployCallback"
>

Re: Disable large messages support at all

[Robbie Gemmell]

The Artemis broker / client handling of 'large' messages, and
'streaming payload to/from file at client' are 2 separate things and
shouldnt be conflated.

The Artemis 'Core' JMS client + broker consider messages over 100kb by
default 'large' and treat them a little differently in terms of how
they are sent by the producer client, and then the broker storing them
differently on disk, and sending them to consuming clients.

The Artemis client can separately leverage a custom Object property to
read/write the BytesMessage body using an InputStream / OutputStream,
e.g to from/to a file, at the application side.

The exception below seems (not 100% clear, as the stack isnt present)
to be saying that while trying to extract the body of a message Camel
actually tried to write to a read-only JMS Message (specifically the
properties of it), and so the qpid-jms client threw because of that,
as it should. That seems like potentially either an issue with your
configuration or a bug in Camel. Guessing, is it possible you/Camel
perhaps configuring things to try inserting the custom 'input/output
stream' Object property used by the Artemis JMS client, even though it
isnt actually using the Artemis client? That certainly might explain
the seeming 'set property while trying to extract body from read-only
message' behaviour. As you are asking here to 'disable large messages'
entirely, it sounds like your messages aren't necessarily all that big
and you dont necessarily need/want the 'stream message to/from file'
input/output stream behaviour at the client side anyway, and if so you
can disable that?

I see you mentioned Camel 3.11. That's pretty old now, perhaps also
try a more recent version to see if it fixed anything that might be in
play here?

There is a second broker-side acceptor URL config parameter,
amqpMinLargeMessageSize, that defaults to 102400 (100kb) and can
change the point at which the broker considers AMQP messages to be
'large' and handles them on disk in similar way as it does the Artemis
Core 'large' messages. Though there are also other considerations
though as Justin said, such as the journal buffer size and file size,
so its not a case of just setting it really large to disable the
behaviour entirely.

On Mon, 4 Sept 2023 at 08:32, Modanese, Riccardo
 wrote:
>
> Hi Justin,
> Thank you for your reply.
> I had no way to get large messages support using Camel routes with Camel-amqp 
> endpoint.
> With Camel-amqp, using qpid connection 
> (org.apache.qpid.jms.JmsConnectionFactory), messages over the default 100kb 
> weren’t processed.
> Camel went to an infinite loop printing this error at each iteration:
>
> 2023-08-23 11:07:18 org.apache.camel.RuntimeCamelException: Failed to extract 
> body due to: javax.jms.MessageNotWriteableException: Message properties are 
> read-only. Message: JmsBytesMessage { 
> org.apache.qpid.jms.provider.amqp.message.AmqpJmsBytesMessageFacade@39dd152c
>  }
> 2023-08-23 11:07:18 at 
> org.apache.camel.component.jms.JmsBinding.extractBodyFromJms(JmsBinding.java:174)
> 2023-08-23 11:07:18 at 
> org.apache.camel.component.jms.JmsMessage.createBody(JmsMessage.java:234)
>
> Switching to core the messages over 100k were handled but no way to change 
> the minimum large messages default value.
>
> From the support I got from Camel mailing list there is no other way than 
> using Camel-jms to have full large messages support:
>
> “I am afraid that in order to use minLargeMessageSize you need to use
> *camel-jms* component and *artemis-jms-client* as jms implementation,
> because camel-amqp uses *qpid-jms-client.*If you have some time, you can
> take a look to camel-jms”
>
> This force us to use the Artemis connection factory 
> (org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory), in our 
> clients, to connect to the broker, decreasing the generality we like to have 
> on our opensource project.
>
> I’m still testing a working configuration with Camel-jms but I was just 
> wondering if there was a way to disable the large messages support.
>
> Riccardo
>
> From: Justin Bertram 
> Date: Friday, 1 September 2023 at 20:56
> To: users@activemq.apache.org 
> Subject: Re: Disable large messages support at all
> There is no way to completely disable large message support. This is
> because clients are free to send messages larger than the configured
> journal-buffer-size (490KB by default). When that happens the broker has no
> choice but to treat the message as "large" and stream it to disk rather
> than storing it in the journal. You can increase the journal-buffer-size to
> make large messages less likely or even effectively eliminate them
> depending on your use-case, but using the larger buffer may have an impact
> on performance.
>
> What "difficulties" are you having currently with AMQP, MQTT, & large
> messages?
>
>
> Justin
>
>
> On Wed, Aug 30, 2023 at 2:21 AM Modanese, R

Re: Disable large messages support at all

[Robbie Gemmell]

Though actually, another thing occurred to me...you said your "clients
are MQTT", in which case the Artemis client minLargeMessageSize config
and broker side amqpMinLargeMessageSize config wont necessarily be in
play if your Camel bits are only consuming messages, as those configs
primarily affect what happens when the Core and AMQP clients are
producing messages. Its not really clear so far what all you are doing
at each component.

On Mon, 4 Sept 2023 at 12:34, Robbie Gemmell  wrote:
>
> The Artemis broker / client handling of 'large' messages, and
> 'streaming payload to/from file at client' are 2 separate things and
> shouldnt be conflated.
>
> The Artemis 'Core' JMS client + broker consider messages over 100kb by
> default 'large' and treat them a little differently in terms of how
> they are sent by the producer client, and then the broker storing them
> differently on disk, and sending them to consuming clients.
>
> The Artemis client can separately leverage a custom Object property to
> read/write the BytesMessage body using an InputStream / OutputStream,
> e.g to from/to a file, at the application side.
>
> The exception below seems (not 100% clear, as the stack isnt present)
> to be saying that while trying to extract the body of a message Camel
> actually tried to write to a read-only JMS Message (specifically the
> properties of it), and so the qpid-jms client threw because of that,
> as it should. That seems like potentially either an issue with your
> configuration or a bug in Camel. Guessing, is it possible you/Camel
> perhaps configuring things to try inserting the custom 'input/output
> stream' Object property used by the Artemis JMS client, even though it
> isnt actually using the Artemis client? That certainly might explain
> the seeming 'set property while trying to extract body from read-only
> message' behaviour. As you are asking here to 'disable large messages'
> entirely, it sounds like your messages aren't necessarily all that big
> and you dont necessarily need/want the 'stream message to/from file'
> input/output stream behaviour at the client side anyway, and if so you
> can disable that?
>
> I see you mentioned Camel 3.11. That's pretty old now, perhaps also
> try a more recent version to see if it fixed anything that might be in
> play here?
>
> There is a second broker-side acceptor URL config parameter,
> amqpMinLargeMessageSize, that defaults to 102400 (100kb) and can
> change the point at which the broker considers AMQP messages to be
> 'large' and handles them on disk in similar way as it does the Artemis
> Core 'large' messages. Though there are also other considerations
> though as Justin said, such as the journal buffer size and file size,
> so its not a case of just setting it really large to disable the
> behaviour entirely.
>
> On Mon, 4 Sept 2023 at 08:32, Modanese, Riccardo
>  wrote:
> >
> > Hi Justin,
> > Thank you for your reply.
> > I had no way to get large messages support using Camel routes with 
> > Camel-amqp endpoint.
> > With Camel-amqp, using qpid connection 
> > (org.apache.qpid.jms.JmsConnectionFactory), messages over the default 100kb 
> > weren’t processed.
> > Camel went to an infinite loop printing this error at each iteration:
> >
> > 2023-08-23 11:07:18 org.apache.camel.RuntimeCamelException: Failed to 
> > extract body due to: javax.jms.MessageNotWriteableException: Message 
> > properties are read-only. Message: JmsBytesMessage { 
> > org.apache.qpid.jms.provider.amqp.message.AmqpJmsBytesMessageFacade@39dd152c<mailto:org.apache.qpid.jms.provider.amqp.message.AmqpJmsBytesMessageFacade@39dd152c>
> >  }
> > 2023-08-23 11:07:18 at 
> > org.apache.camel.component.jms.JmsBinding.extractBodyFromJms(JmsBinding.java:174)
> > 2023-08-23 11:07:18 at 
> > org.apache.camel.component.jms.JmsMessage.createBody(JmsMessage.java:234)
> >
> > Switching to core the messages over 100k were handled but no way to change 
> > the minimum large messages default value.
> >
> > From the support I got from Camel mailing list there is no other way than 
> > using Camel-jms to have full large messages support:
> >
> > “I am afraid that in order to use minLargeMessageSize you need to use
> > *camel-jms* component and *artemis-jms-client* as jms implementation,
> > because camel-amqp uses *qpid-jms-client.*If you have some time, you can
> > take a look to camel-jms”
> >
> > This force us to use the Artemis connection factory 
> > (org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory), in our 
>

Re: Disable large messages support at all

[Robbie Gemmell]

Neither the client-side minLargeMessage or broker-side
amqpMinLargeMessage config will have much effect if you are only
consuming from camel / JMS client, since as before they mainly
influence publishing. The Artemis JMS client sends messages 'large'
slightly differently, doing this when its minLargeMessage size is
exceeded (it has a default of 100kb). The broker persists published
AMQP messages differently as they arrive if they exceed the brokers
amqpMinLargeMessageSize (and has a default of 100kb).

AMQP doesnt have distinct 'large' and 'not large' messages, thats why
"minLargeMessage" config isnt/wont-be supported for Camel AMQP
endpoints, since it is an Artemis client/protocol specific
configuration, and not something the Qpid JMS client uses.

Again I'd suggest you give a newer Camel a try, perhaps there have
been bugs there which have been fixed. For example you are using 3.11
but I see in the upgrade details for the very next version that they
changed the default behaviour so you have to explicitly enable the
seperate artemis-specific 'special input/output-stream Object
property' handling stuff (via artemisStreamingEnabled option), which
I'd guess is exactly what is causing your problem due to Camel trying
it with the non-artemis client.
https://github.com/apache/camel/blob/26b156bc3d7c85bc629f2ca14f852bc16273f023/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_12.adoc#camel-jms

On Mon, 4 Sept 2023 at 16:27, Modanese, Riccardo
 wrote:
>
> I was just wondering if there was a way to disable, or at least force 
> globally from server side, a value for that parameter.
> I mean, the default value is in some way enforced by the broker if no 
> override is done. So, in the same way, I was wondering if this default 
> parameter could be changed without adding any parameter to acceptors or 
> connection strings (according to the journal buffer size, obviously, that 
> anyway could be changed by configuration right? - 
> my_value)
>
> I mentioned MQTT clients to give a picture of our configuration.
> Our Artemis exposes 3 acceptors. 2 MQTT for IoT clients with 2 ways load 
> (each client publishes and subscribes different topics) and one AMQP for 
> consumers (Camel +  streams configured) implementing business logic.
>
> The Camel routes steps have generic signature (Exchange, Object) and in the 
> full stack trace (I partially reported here) there wasn't any of our class 
> involved. (I know Object is redundant, but I preferred instead of getting it 
> from exchange.in in every method)
>
> With my original route configuration, I tried to set the amqpMinLargeMessage 
> and minLargeMessage to both the acceptor and the connection string on client 
> side but without any effect.
>
> I already received support from Camel mailing list and they suggested me to 
> switch to Camel-jms since Camel-amqp doesn’t support the minLargeMessage 
> (though in my tests I was able to get the stream from Artemis once I switched 
> to use core instead of amqp)
>
> I’m looking forward to see the minLargeMessage supported by Camel streams 
> also with amqp endpoint.
>
> From: Robbie Gemmell 
> Date: Monday, 4 September 2023 at 14:11
> To: users@activemq.apache.org 
> Subject: Re: Disable large messages support at all
> Though actually, another thing occurred to me...you said your "clients
> are MQTT", in which case the Artemis client minLargeMessageSize config
> and broker side amqpMinLargeMessageSize config wont necessarily be in
> play if your Camel bits are only consuming messages, as those configs
> primarily affect what happens when the Core and AMQP clients are
> producing messages. Its not really clear so far what all you are doing
> at each component.
>
> On Mon, 4 Sept 2023 at 12:34, Robbie Gemmell  wrote:
> >
> > The Artemis broker / client handling of 'large' messages, and
> > 'streaming payload to/from file at client' are 2 separate things and
> > shouldnt be conflated.
> >
> > The Artemis 'Core' JMS client + broker consider messages over 100kb by
> > default 'large' and treat them a little differently in terms of how
> > they are sent by the producer client, and then the broker storing them
> > differently on disk, and sending them to consuming clients.
> >
> > The Artemis client can separately leverage a custom Object property to
> > read/write the BytesMessage body using an InputStream / OutputStream,
> > e.g to from/to a file, at the application side.
> >
> > The exception below seems (not 100% clear, as the stack isnt present)
> > to be saying that while trying to extract the body of a message Camel
> > actually tried to write to a read-only JMS Mes

Re: Disable large messages support at all

[Robbie Gemmell]

I dont know know about that issue, no. Seems like it happens due to
converting from a 'large' Core message (which I believe is used for
MQTT too) into an AMQP message. That would happen after it was on the
queueso of course the publisher got an ack. The exception seems to
indicate the conversion failed as the 'large' message was already
closed, unclear why that would be, per the previous comments. The
JIRA/stack indicates the message was actually sent to the Dead Letter
Address rather than just discarded, was it? I believe one for 'DLQ' is
configured by default.

On Wed, 13 Sept 2023 at 14:53, Modanese, Riccardo
 wrote:
>
> Thank you Robbie, upgrading Camel to the latest 3.x available fixed the 
> problem but I experienced messages loss.
>
> The broker log showed exactly the stack trace of this issue:
> https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-4217
>
> Unfortunately I didn’t detect a cause for this. It happened with just few 
> messages of different sizes sent. But trying the same test again later didn’t 
> replicate the error (anyway the MQTT message payload was randomly generated). 
> And I had no chance to verify if the message discarded was delivered anyway 
> to consumers attached to the same connector (MQTT)
> Do you have any idea about the ETA for a resolution of this issue?
> What is worse is that my client receives the ack for the MQTT messages with 
> the QoS 1 the broker discarded due to conversion error. So these messages are 
> not delivered to my AMQP consumers but the client is not aware of that and 
> couldn’t try another send.
> I know that formally QoS 1 only guarantees that the message has been 
> received, and cannot guarantee its correct processing, however in this case 
> it's not clear why the message has been discarded, which makes intercepting 
> such errors very hard.
>
>
> From: Robbie Gemmell 
> Date: Monday, 4 September 2023 at 19:08
> To: users@activemq.apache.org 
> Subject: Re: Disable large messages support at all
> Neither the client-side minLargeMessage or broker-side
> amqpMinLargeMessage config will have much effect if you are only
> consuming from camel / JMS client, since as before they mainly
> influence publishing. The Artemis JMS client sends messages 'large'
> slightly differently, doing this when its minLargeMessage size is
> exceeded (it has a default of 100kb). The broker persists published
> AMQP messages differently as they arrive if they exceed the brokers
> amqpMinLargeMessageSize (and has a default of 100kb).
>
> AMQP doesnt have distinct 'large' and 'not large' messages, thats why
> "minLargeMessage" config isnt/wont-be supported for Camel AMQP
> endpoints, since it is an Artemis client/protocol specific
> configuration, and not something the Qpid JMS client uses.
>
> Again I'd suggest you give a newer Camel a try, perhaps there have
> been bugs there which have been fixed. For example you are using 3.11
> but I see in the upgrade details for the very next version that they
> changed the default behaviour so you have to explicitly enable the
> seperate artemis-specific 'special input/output-stream Object
> property' handling stuff (via artemisStreamingEnabled option), which
> I'd guess is exactly what is causing your problem due to Camel trying
> it with the non-artemis client.
> https://github.com/apache/camel/blob/26b156bc3d7c85bc629f2ca14f852bc16273f023/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_12.adoc#camel-jms
>
> On Mon, 4 Sept 2023 at 16:27, Modanese, Riccardo
>  wrote:
> >
> > I was just wondering if there was a way to disable, or at least force 
> > globally from server side, a value for that parameter.
> > I mean, the default value is in some way enforced by the broker if no 
> > override is done. So, in the same way, I was wondering if this default 
> > parameter could be changed without adding any parameter to acceptors or 
> > connection strings (according to the journal buffer size, obviously, that 
> > anyway could be changed by configuration right? - 
> > my_value)
> >
> > I mentioned MQTT clients to give a picture of our configuration.
> > Our Artemis exposes 3 acceptors. 2 MQTT for IoT clients with 2 ways load 
> > (each client publishes and subscribes different topics) and one AMQP for 
> > consumers (Camel +  streams configured) implementing business logic.
> >
> > The Camel routes steps have generic signature (Exchange, Object) and in the 
> > full stack trace (I partially reported here) there wasn't any of our class 
> > involved. (I know Object is redundant, but I preferred instead of getting 
> > it from exchange.in in eve

Re: Disable large messages support at all

[Robbie Gemmell]

The issue definitely seems to be in the 'large Core message'->AMQP
conversion, so for now the only way to avoid it until fixed would seem
to be to avoid that process.

For MQTT senders as you are using, it looks like perhaps the messages
are treated as 'large' if they are greater than the minimum of the
brokers journal-buffer-size (default ~490KB) and the journal-file-size
(default ~10M), so you might be able to influence things playing with
those configs (mainly the former) such that the messages aren't
treated as large...though not sure how advisable that actually is, and
it would depend on your actual use case if a usable value was even
feasible.

On Wed, 13 Sept 2023 at 16:45, Robbie Gemmell  wrote:
>
> I dont know know about that issue, no. Seems like it happens due to
> converting from a 'large' Core message (which I believe is used for
> MQTT too) into an AMQP message. That would happen after it was on the
> queueso of course the publisher got an ack. The exception seems to
> indicate the conversion failed as the 'large' message was already
> closed, unclear why that would be, per the previous comments. The
> JIRA/stack indicates the message was actually sent to the Dead Letter
> Address rather than just discarded, was it? I believe one for 'DLQ' is
> configured by default.
>
> On Wed, 13 Sept 2023 at 14:53, Modanese, Riccardo
>  wrote:
> >
> > Thank you Robbie, upgrading Camel to the latest 3.x available fixed the 
> > problem but I experienced messages loss.
> >
> > The broker log showed exactly the stack trace of this issue:
> > https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-4217
> >
> > Unfortunately I didn’t detect a cause for this. It happened with just few 
> > messages of different sizes sent. But trying the same test again later 
> > didn’t replicate the error (anyway the MQTT message payload was randomly 
> > generated). And I had no chance to verify if the message discarded was 
> > delivered anyway to consumers attached to the same connector (MQTT)
> > Do you have any idea about the ETA for a resolution of this issue?
> > What is worse is that my client receives the ack for the MQTT messages with 
> > the QoS 1 the broker discarded due to conversion error. So these messages 
> > are not delivered to my AMQP consumers but the client is not aware of that 
> > and couldn’t try another send.
> > I know that formally QoS 1 only guarantees that the message has been 
> > received, and cannot guarantee its correct processing, however in this case 
> > it's not clear why the message has been discarded, which makes intercepting 
> > such errors very hard.
> >
> >
> > From: Robbie Gemmell 
> > Date: Monday, 4 September 2023 at 19:08
> > To: users@activemq.apache.org 
> > Subject: Re: Disable large messages support at all
> > Neither the client-side minLargeMessage or broker-side
> > amqpMinLargeMessage config will have much effect if you are only
> > consuming from camel / JMS client, since as before they mainly
> > influence publishing. The Artemis JMS client sends messages 'large'
> > slightly differently, doing this when its minLargeMessage size is
> > exceeded (it has a default of 100kb). The broker persists published
> > AMQP messages differently as they arrive if they exceed the brokers
> > amqpMinLargeMessageSize (and has a default of 100kb).
> >
> > AMQP doesnt have distinct 'large' and 'not large' messages, thats why
> > "minLargeMessage" config isnt/wont-be supported for Camel AMQP
> > endpoints, since it is an Artemis client/protocol specific
> > configuration, and not something the Qpid JMS client uses.
> >
> > Again I'd suggest you give a newer Camel a try, perhaps there have
> > been bugs there which have been fixed. For example you are using 3.11
> > but I see in the upgrade details for the very next version that they
> > changed the default behaviour so you have to explicitly enable the
> > seperate artemis-specific 'special input/output-stream Object
> > property' handling stuff (via artemisStreamingEnabled option), which
> > I'd guess is exactly what is causing your problem due to Camel trying
> > it with the non-artemis client.
> > https://github.com/apache/camel/blob/26b156bc3d7c85bc629f2ca14f852bc16273f023/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_12.adoc#camel-jms
> >
> > On Mon, 4 Sept 2023 at 16:27, Modanese, Riccardo
> >  wrote:
> > >
> > > I was just wondering if there was a way to disable, or at least force 
> > > globally from server s

Re: Official Container Image Issue

[Robbie Gemmell]

The referenced functionality was only added recently [1] for 2.31.0 as
you noted, and so not surprisingly isnt available in 2.30.0. The
change will be included in 2.31.0. A candidate is currently under
release vote [2] and so all being well 2.31.0 should be available in
the coming days.

[1] https://issues.apache.org/jira/browse/ARTEMIS-4408
[2] https://lists.apache.org/thread/4wt20tsvzfooqbp33zrk5tvkd7cgpwx5

On Tue, 19 Sept 2023 at 09:10, John, Richard
 wrote:
>
> Hi.
>
> We have downloaded the new official container image of Apache ActiveMQ 
> Artemis (v2.30.0) from dockerhub and are using it to (scripted) build and run 
> our own containers for deployment (applying our own specific config over the 
> default for broker.xml, management.xml, log4j2.properties, login.config etc).
>
> We are seeing an issue, when placing the aforementioned files in the 
> /etc-override folder, they aren't being overridden in the /etc folder (we 
> have noted the issue&commit in 
> https://github.com/apache/activemq-artemis/commit/fd5b64f035aa4a7ec8d4a5951818ee331a8d3a62
>  which fixes this but isn't in 2.30.0 at present.
>
> So we have a couple of questions-
>
> Is there a workaround to this issue (we have tried copying the files via a 
> script during the build and run process but it fails due to permissions - 
> possibly as the file isn't owned by Artemis user
> Will the above fix be included in 2.31.0 and if so, when is that due to be 
> published?
>
> Thanks
>
>
> 
>
> Capgemini is a trading name used by the Capgemini Group of companies which 
> includes Capgemini UK plc, a company registered in England and Wales (number 
> 943935) whose registered office is at No. 1, Forge End, Woking, Surrey, GU21 
> 6DB.
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is intended only for the person to 
> whom it is addressed. If you are not the intended recipient, you are not 
> authorized to read, print, retain, copy, disseminate, distribute, or use this 
> message or any part thereof. If you receive this message in error, please 
> notify the sender immediately and delete all copies of this message.

[ANNOUNCE] ActiveMQ Artemis 2.31.2 released

[Robbie Gemmell]

I am pleased to announce the release of ActiveMQ Artemis 2.31.2

Downloads are now available at:
https://activemq.apache.org/components/artemis/download/

For a complete list of updates:
https://activemq.apache.org/components/artemis/download/release-notes-2.31.2

This is a bug fix release.

Thanks to all who helped on this release.

Robbie

Re: Jakarta dependencies

[Robbie Gemmell]

Yes that list looks correct re: Jakarta..

For 5.x/6.x there are some relevant details at
https://activemq.apache.org/jms2 around the ongoing JMS 2 and now
Jakarta Messaging 3.1 work that might answer your questions.

For Artemis, there are relevant details at
https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html#the-client-classpath
although the 'since version' isnt detailed since the docs are
version-specific. Jakarta support has been there since 2021 though, so
you shouldn't be using anything old enough for versions to matter.

On the JVM side..not aware of any tables like the Gradle one, but I
believe they tend to need specific support adding more often.

For Artemis, the PR build and test subset has been working on Java 21
since before its release so I'd expect that to work ok, and anything
not doing so would be considered a bug to fix.

I dont know about 5.x/6.x for sure, but I'd personally expect the same
at this point (especially on 6.x given it will have a Java 17
minimum).

Robbie

On Fri, 3 Nov 2023 at 08:21, ski n  wrote:
>
> I'm planning to move to Jakarta namespace (JEE10). What I understand is:
>
> 1. ActiveMQ Classic Server: Jakarta is not supported (but will be soon from
> version 6).
> 2. ActiveMQ Classic Client: Jakarta is supported.
> 3. ActiveMQ Artemis Server: Jakarta is supported.
> 4. ActiveMQ Artemis Client: Jakarta is supported.
>
> Is this correct?
>
> For some dependencies, I need specific Jakarta ones. Is there an overview
> (a table) for both Classic and Artemis with the list of dependencies for
> javax and jakarta and from which version this is supported. It's practical
> to known when to change the dependency artifact name, but also interesting
> when it stays the same.
>
> 
>
> I'm also planning to upgrade the Java version. Do the latest versions also
> support Java 21, or should I stick with Java 17 for now? Is here also an
> overview table for both classic and artemis? Similar to the compatibility
> matrix of Gradle:
>
> https://docs.gradle.org/current/userguide/compatibility.html
>
> Thanks,
>
> Raymond

Re: auto-delete on addresses that still have a producer

[Robbie Gemmell]

nitpick: AMQP 1.0 also supports 'named producers'. Thats actually all
the protocol supported until an additional capability was documented
for doing 'anonymous producer' stuff as e.g needed by some of JMS 1.1.
Though its worth noting all producers on the 'simplified api' added in
JMS 2.0 are effectively anonymous.

On Fri, 3 Nov 2023 at 15:48, Justin Bertram  wrote:
>
> The broker does its best to track producers, but most protocols don't even
> have the concept of a "named" producer (i.e. a producer that's registered
> on the server to a particular endpoint). Most protocols only support
> "anonymous" producers which can send to any endpoint at any time which
> means in most circumstances the broker doesn't actually know when a client
> is going to send a message (if at all) and when a client does send a
> message the broker doesn't know where it's going to go until it actually
> arrives.
>
> The only API I'm aware of that has named producers is JMS and even JMS
> supports anonymous producers. Furthermore, of the three protocols used by
> JMS clients (i.e. core, OpenWire, and AMQP) only OpenWire supports named
> producers.
>
> In short, there's no real way for the broker to know when there's a
> producer "on" an address.
>
> The situation for consumers is, of course, the complete opposite. The
> broker must know about consumers so it can dispatch messages to them.
>
> Ultimately if an address is removed while a slow producer is still sending
> messages to it then it will be re-created automatically if the
> configuration supports that.
>
> Hope that helps!
>
>
> Justin
>
> On Fri, Nov 3, 2023 at 9:17 AM Dondorp, Erwin 
> wrote:
>
> > Classification: Public
> >
> > Hello,
> >
> > Today I noticed that an address was auto-removed while it still had a
> > producer active.
> > The producer has a very low production rate, its interval was above the
> > value of auto-delete-addresses-delay, so the timing constraints were still
> > ok.
> > Nothing was broken and I can easily increase auto-delete-addresses-delay.
> >
> > In the source-code, in function "reapAddresses", it looks to me as if
> > Artemis does not try to prevent such address-removal with a producer
> > present.
> >
> > Therefore, the question remains:
> > Should an address be auto-removed when there still is a producer active?
> >
> > thx!
> > Erwin
> >
> > 
> >
> > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> > die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> > (en eventuele bijlagen) te vernietigen.
> >
> > Informatie vennootschap
> >

Re: [ActiveMQ Classic] Broker dependencies in 5.18.3

[Robbie Gemmell]

Something about your specific build is making Maven select 5.18.2 for
those modules, as the 5.18.3 broker module does originally depend on
the 5.18.3 modules.

Maven will resolve all the [transitive] dependencies of your build,
and pick one version for everything used. In that process, something
is making it pick 5.18.2 for the other modules. Its likely you either
have other dependencies in your build that [transitively] depend on
the 5.18.2 client etc, and the resolution is selecting those versions
as they are somehow 'closer' (explained somewhat in
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#transitive-dependencies),
or else perhaps you have some dependencyManagement in play somehow
that is setting it (check any bom/pom imports, or parent poms you are
using, if you dont think you are doing it directly...see also
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
for more detail). You can ensure what is picked using your own
dependencyManagement declarations.

You can examine what is being picked and why using: "mvn
dependency:tree" to see the effective selection path, and "mvn
dependency:tree -Dverbose" to see various added details otherwise
omitted by default.

You can examine the actual effective pom for your build once
inheritance etc is considered, and see where each effective line is
actually coming from, using "mvn help:effective-pom -Dverbose"


On Wed, 22 Nov 2023 at 10:12, PERRIN COMBALUZIER Gaetan
 wrote:
>
> Hello Team,
>
> I'm using ActiveMQ broker on multiple projects, and we just made the update 
> from 5.18.2 to 5.18.3 to correct CVE-202346604.
>
> In my maven dependencies, I just declare activemq-broker and let him handle 
> his dependencies.
>
> However, he seems to download his ActiveMQ dependencies (activemq-client and 
> activemq-openwire-legacy) in 5.18.2.
>
> Is it normal ? Shouldn't it go for 5.18.3 ?
>
> Obviously, I can work around it by declaring myself which version of each 
> dependency I want, but I'm surprised maven doesn't take care of it by himself.
>
> Regards,
>
> Gaétan Perrin
>
>
> AVIS : Ce courrier et ses pieces jointes sont destines a leur seul 
> destinataire et peuvent contenir des informations confidentielles appartenant 
> a bioMerieux. Si vous n'etes pas destinataire, vous etes informe que toute 
> lecture, divulgation, ou reproduction de ce message et des pieces jointes est 
> strictement interdite. Si vous avez recu ce message par erreur merci d'en 
> prevenir l'expediteur et de le detruire, ainsi que ses pieces jointes. 
> NOTICE: This message and attachments are intended only for the use of their 
> addressee and may contain confidential information belonging to bioMerieux. 
> If you are not the intended recipient, you are hereby notified that any 
> reading, dissemination, distribution, or copying of this message, or any 
> attachment, is strictly prohibited. If you have received this message in 
> error, please notify the original sender immediately and delete this message, 
> along with any attachments.

Re: GPG verification of apache-artemis 2.31.2

[Robbie Gemmell]

You are not missing anything, unfortunately I updated the
redundant/unused 'dist dev area' KEYS file rather than the 'dist
release area' KEYS file when I did the release, so when you checked
earlier it simply didnt contain the appropriate key. It went unnoticed
presumably as most people checking the release during the vote already
have my key from other releases elsewhere.

I have updated the proper release area file now, and removed the
redundant/unused dev one to avoid a repeat, so its now available in
the file at: https://downloads.apache.org/activemq/KEYS

Robbie

On Wed, 13 Dec 2023 at 14:11, Riccardo Caselli  wrote:
>
> Hi,
>
> I'm trying to follow these instructions
> https://activemq.apache.org/components/artemis/download/#verify-the-integrity-of-downloads
> to verify the archive of apache-artemis-2.32.2.tar.gz (I tried also with
> the zip), but it seems it's not working as expected, am I missing something?
>
> $ gpg --import KEYS
> gpg: key 9FF25980F5BA7E4F: public key "Hiram Chirino "
> imported
> gpg: key FEFEFED7A2F9E313: 1 signature not checked due to a missing key
> gpg: key FEFEFED7A2F9E313: public key "David Jencks (CODE SIGNING KEY) <
> djen...@apache.org>" imported
> gpg: key DCEBFD5F43C5BCC7: 1 signature not checked due to a missing key
> gpg: key DCEBFD5F43C5BCC7: public key "Jim Gomes (Apache Software
> Foundation Key) " imported
> gpg: key A05EBEE656F3E01B: public key "David Jencks (geronimo) <
> david_jen...@yahoo.com>" imported
> gpg: key D2E3BE73456DFEA9: public key "David M. Johnson (Dave Johnson) <
> snoopd...@apache.org>" imported
> gpg: key FD9ED9F117AA5B25: 14 signatures not checked due to missing keys
> gpg: key FD9ED9F117AA5B25: public key "David Johnson "
> imported
> gpg: key F135DBE269CC103E: public key "Gary Tully (key for apache releases)
> " imported
> gpg: key FEEA5B232C983957: public key "Bruce Snyder "
> imported
> gpg: key C31A3F706852C7DA: public key "Dejan Bosanac "
> imported
> gpg: key 62ED4DF0BACB8793: public key "Dejan Bosanac "
> imported
> gpg: key 152266726A70C608: 1 signature not checked due to a missing key
> gpg: key 152266726A70C608: public key "Hadrian Zbarcea "
> imported
> gpg: key E0067B722B1A9558: public key "Claus Ibsen "
> imported
> gpg: key 0F0E47D4BB8FA6E3: 1 signature not checked due to a missing key
> gpg: key 0F0E47D4BB8FA6E3: public key "Arthur Naseef (4K Personal Key for
> Arthur Naseef created January 2015) " imported
> gpg: key 858FC4C4F43856A3: 40 signatures not checked due to missing keys
> gpg: key 858FC4C4F43856A3: public key "J. Daniel Kulp "
> imported
> gpg: key 7EF9AB1DF5A0DF5D: public key "Timothy Bish "
> imported
> gpg: key 1B161203012672EB: public key "Timothy Bish (CODE SIGNING KEY) <
> tabish...@gmail.com>" imported
> gpg: key 87A7F75A6A8BA5FC: public key "Christopher L. Shannon (CODE SIGNING
> KEY) " imported
> gpg: key 76986236CDA7ADF1: public key "Martyn Taylor "
> imported
> gpg: key 54A43F3254868410: public key "Clebert Suconic (
> clebertsuco...@apache.org) " imported
> gpg: key F65D88E0295B2B2F: public key "John D. Ament "
> imported
> gpg: key A64A5C2C6626D4BF: public key "Justin Bertram "
> imported
> gpg: key 1AD14F48D0EBE407: public key "Michael Andre Pearce (CODE SIGNING
> KEY) " imported
> gpg: key BFF2EE42C8282E76: public key "Jean-Baptiste Onofré <
> jbono...@apache.org>" imported
> gpg: key 2FA68D868BC04736: public key "Krzysztof Porebski (CODE SIGNING
> KEY) " imported
> gpg: key AA243E5D87E3F303: public key "Gary Tully (CODE SIGNING KEY) <
> gtu...@apache.org>" imported
> gpg: key C787CD44D8E0CAAB: public key "Domenico Francesco Bruscino <
> brus...@apache.org>" imported
> gpg: key F41830B875BB8633: public key "Justin Bertram "
> imported
> gpg: Total number processed: 27
> gpg:   imported: 27
> gpg: marginals needed: 3  completes needed: 1  trust model: pgp
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
>
>
> $ gpg --verify apache-artemis-2.31.2-bin.tar.gz.asc
> gpg: assuming signed data in 'apache-artemis-2.31.2-bin.tar.gz'
> gpg: Signature made Fri 27 Oct 2023 12:22:42 PM CEST
> gpg:using RSA key EA3C1038565EB6A004B0764D74D820B854FDD85D
> gpg: Can't check signature: No public key
>
> Thanks,
> Riccardo

Re: Need help in connecting to embedded broker from external client

[Robbie Gemmell]

You specifically note trying STOMP and AMQP clients, however you make
no mention of bringing in the STOMP or AMQP protocol dependencies to
enable support of those protocols. Have you?

The artemis-jms-server dependency only brings in support for the CORE
protocol, used by artemis-jms-client for example. For AMQP support you
would add the artemis-amqp-protocol dependency, and for STOMP it would
be artemis-stomp-protocol.

I think you might also have to configure the acceptor URL(s) to
indicate which protocols you want it to support, with e.g
"?protocols=CORE,AMQP,STOMP". As an example, the template file used to
generate the broker.xml config during standalone broker (which
includes all the protocol modules) instance creation has an acceptor
supporting all the protocols (and template variables for the others
that are protocol-specific):
https://github.com/apache/activemq-artemis/blob/2.31.2/artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/etc/broker.xml#L101

On Thu, 14 Dec 2023 at 04:54, Shurya kumar  wrote:
>
> Hi all,
>
> I am using an embedded Artemis broker in my Springboot application.
> I am able to use the broker from the java application.
>
> However, when i try to connect to broker from the python client using
> stomp/amqp, it is not getting connected. But the telnet command is
> able to the port.
>
> Is there something i am missing?
>
>
> Pom.xml
> ---
>
> 
> org.springframework.boot
> spring-boot-starter-artemis
> 
>
> 
> 
> org.apache.activemq
> artemis-jms-server
> 2.19.0
> 
>
> 
> org.messaginghub
> pooled-jms
> 
>
>
> Config
> --
>
> @Configuration
> public class ArtemisConfig implements ArtemisConfigurationCustomizer {
>   @Override
>   public void customize(org.apache.activemq.artemis.core.config.Configuration
> configuration) {
> try {
>   configuration.addAcceptorConfiguration("remote", "tcp://0.0.0.0:5672");
>   configuration.setSecurityEnabled(false);
> } catch (Exception e) {
>   throw new RuntimeException(e);
> }
>   }
> }
>
>
> application.properties
> -
>
> spring.artemis.embedded.enabled=true
> spring.artemis.mode=embedded
> # Customize host, port, username, and password
> spring.artemis.user=admin
> spring.artemis.password=Test.1
> spring.artemis.broker-url=tcp://127.0.0.1:8990
> spring.artemis.pool.enabled=true
> spring.artemis.pool.max-connections=50
> logging.level.org.apache.activemq.artemis=DEBUG

Re: Need help in connecting to embedded broker from external client

[Robbie Gemmell]

Should have read all the mails first. Your python code below is almost
certainly for an AMQP 0-x protocol client but note that Artemis
supports clients using the AMQP 1.0 ISO standard protocol, so you
won't be able to use that client with Artemis even once you set the
dependencies+acceptor up correctly.

On Thu, 14 Dec 2023 at 10:08, Shurya kumar  wrote:
>
> I was doing telnet on 8990.
>
> --telnet 127.0.0.1 8990
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> Connection closed by foreign host.
>
>
> -
> I tried with making the ports as same in the broker url and acceptor.
> Port used was 5672
>
> In both the scenarios, the server logs was showing
>
> 2023-12-14 15:33:14.362 DEBUG 12156 --- [ost-1787830293)]
> o.a.a.a.c.r.s.i.RemotingServiceImpl  :
> RemotingServiceImpl::removing connection ID 43b1acbd
>
> And in the python client, it threw the following after 10 seconds
>
> Traceback (most recent call last):
>
>   File "please_work.py", line 8, in 
>
> connection = pika.BlockingConnection(pika.URLParameters(broker_url))
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pika/adapters/blocking_connection.py",
> line 360, in __init__
> self._impl = self._create_connection(parameters, _impl_class)
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pika/adapters/blocking_connection.py",
> line 451, in _create_connection
> raise self._reap_last_connection_workflow_error(error)
> pika.adapters.utils.connection_workflow.AMQPConnectorStackTimeout:
> Timeout during AMQP handshake'127.0.0.1'/(,
> , 6, '', ('127.0.0.1', 5672)); ssl=False
>
>
> The following is the python code being used
>
> import pika
>
> # Connection parameters
> broker_url = 'amqp://127.0.0.1:5672'
> queue_name = 'TEST'
>
> # Establish a connection to the broker
> connection = pika.BlockingConnection(pika.URLParameters(broker_url))
> channel = connection.channel()
>
> # Declare a queue
> channel.queue_declare(queue=queue_name)
>
>
> # Send a message to the queue
> message_body = 'Hello from Python!'
> channel.basic_publish(exchange='', routing_key=queue_name, body=message_body)
> print(f" [x] Sent '{message_body}'")

Re: Filtrering issue when header is missing

[Robbie Gemmell]

I believe that's expected because =NULL is unknown.

The filtering is essentially the SQL92 subset JMS / Jakarta Messaging
outlines here:
https://jakarta.ee/specifications/messaging/3.1/apidocs/jakarta.messaging/jakarta/jms/message

Note it outlines that "If a property that does not exist in a message
is referenced, its value is NULL", and then later that for a
comparison operator like =, "If either of the type values evaluates to
NULL, the value of the expression is unknown."

On Tue, 16 Jan 2024 at 10:41, Calle Andersson
 wrote:
>
> Hi,
>
> I’m not sure if I have discovered a bug in Artemis (2.31.2) or if I have 
> misunderstood something.
>
> I used the following command to create a new instance:
> apache-artemis-2.31.2/bin/artemis create --user admin --password admin 
> --no-autocreate --require-login myBroker
>
> I have added the following address:
> 
>  
>name="TEST.QUEUE.A">
>   
>  
>   
>  
> 
>
> When sending a message with the “MyHeader” header set to “ipsum”, the message 
> ends up on the queue (as expected).
>
> However, if the “MyHeader” header is missing, the message simply disappears. 
> E.g. when using the following command:
> ./artemis producer --url tcp://localhost:61616  --user admin --password admin 
> --message-count 1 --destination TEST.QUEUE.A --message "no header"
> (BTW, is it somehow possible to specify custom headers when using the 
> producer command? I’ve not seen any information about support for that but it 
> could be handy in some cases.)
>
> I expected messages without “MyHeader” header to end up on the queue (given 
> the filter above). Instead, I have to use the following filter to make 
> messages without the header to end up on the queue:
> 
>
> Is this a bug or a feature?
>
> Regards,
> Calle
>

Re: REST Interface for Artemis Broker

[Robbie Gemmell]

Just FYI for anyone reading the thread later...

The latest release docs are found at:
https://activemq.apache.org/components/artemis/documentation/

Specifically, the user manual for the latest release (2.31.2 for a few
more days) is found at:
https://activemq.apache.org/components/artemis/documentation/latest

When the latest release is superseded by a newer one the old docs
become available in a versioned subdir (referenced along with the old
release from the past releases page, which is linked from the main
docs and downloads areas of the site), so e.g the original docs link
referenced was from the Artemis 1.0.0 release back in 2015.

The REST component removal was detailed in the 2.26.0 release notes on
the site and in the 2.26.0 entry of the 'versions' page of the docs:
https://activemq.apache.org/components/artemis/documentation/latest/versions.html#2-26-0

On Thu, 25 Jan 2024 at 08:55, Domenico Francesco Bruscino
 wrote:
>
> Hi Shiv,
>
> the REST interface was removed in 2.26.0. You can find the original
> discussion regarding removal here [1]. The recommended alternative is the
> STOMP protocol that is ubiquitous, simple, standardized, and can be used in
> almost every circumstance and environment where REST might be used.
>
> https://lists.apache.org/thread/qcdg5r1ytf0scr05b9wxyxg0stxgs5pp
>
> Regards,
> Domenico
>
>
>
> On Thu, 25 Jan 2024 at 08:36, Shiv Kumar Dixit
>  wrote:
>
> > Hi,
> > I am looking to explore an HTTP based mechanism to send/receive messages
> > to broker.
> >
> > Came across this link which explains setup of REST interface in Artemis
> > broker -
> > https://activemq.apache.org/components/artemis/documentation/1.0.0/rest.html.
> > But the link seems from old documentation. If this REST interface is still
> > valid and available with latest Artemis 2.31.2 broker?
> >
> > Or if there is any other recommendation to use HTTP based
> > producer/consumer?
> >
> > Thanks
> > Shiv
> >

Re: Slack invitation

[Robbie Gemmell]

The invite I'll need to leave to someone else...


I'm not sure what your questions are, but Artemis does not implement
the "AMQP Management Version 1.0" extension though. I believe it was
only ever at working-draft stage, i.e there is actually no Version 1.0
yet really, and I dont think there has been any activity around it in
a number of years now.

None of that is to say you can't manage Artemis over messaging using
AMQP though, just not that particular "AMQP Management" draft
extension.

https://activemq.apache.org/components/artemis/documentation/latest/management.html
has some details around using 'management messages' to manage the
broker. Although the doc is more aimed at the Core client originally,
the same general message-based request and  [temporary] reply-to queue
response-message based approach is generally applicable to the other
protocols the broker supports as well like AMQP.

There is a management example that uses the JMS API client that can
presumably be adapted:
https://github.com/apache/activemq-artemis-examples/blob/6958316d39b01f67add3c2f90a1bf75f62c39020/examples/features/standard/management/src/main/java/org/apache/activemq/artemis/jms/example/ManagementExample.java

There is a test that does some basic management over AMQP using the
codebase own AMQP test client, ultimately doing the same basic thing
as the documentation covers and the JMS client example did:
https://github.com/apache/activemq-artemis/blob/2.32.0/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpManagementTest.java#L49

I recall an old codebase using this same general approach via a
javascript AMQP client years ago:
https://github.com/EnMasseProject/enmasse/blob/0.34.0-rc2/agent/lib/artemis.js


On Tue, 6 Feb 2024 at 08:19, David Ansari
 wrote:
>
> Hello,
>
> I have a couple of questions on how Artemis implements the AMQP Management
> Version 1.0 extension.
> Could you send me an invite to your Slack, please, so that I can ask my
> questions there?
>
> Thank you
> David
>
> --
> This electronic communication and the information and any files transmitted
> with it, or attached to it, are confidential and are intended solely for
> the use of the individual or entity to whom it is addressed and may contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are
> not the intended recipient or the person responsible for delivering the
> e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.

Re: Slack invitation

[Robbie Gemmell]

Its fair to say the management spec effort lost its steam right around
the time of those later drafts, so I doubt anything truly implements
it. I know Qpid Broker-J definitely implements earlier AMQP Management
drafts, say from 8+ years ago. I dont really recall what differed in
later drafts of the management spec at this point, its close to 5
years since then and I wasnt that involved on the management stuff
anyway. Qpid Dispatch router also uses an earlier AMQP-Management like
interface for all its management tools, but again not really the later
draft, and I similarly dont know much detail there.

Most servers these days seem to simply allow pre-defining things, or
auto-creating things (user favourite), or using naming conventions for
specific functionality, or have other message-based / http-based /
jmx-based management interfaces for more nuanced cases, or most often
all of the above. Theres also the implicit subscription style handling
from 'jms topic-like nodes' that just handle many users cases, i.e
they dont actually need to create specific queues as its done for them
in the background. There have definitely been the occasional questions
about more specific client-side management, quite often from 0-x model
users used to it because the 0-x model essentially encouraged it. I
initially thought you were one such user just asking how to do such
things with Artemis hehe.

On Tue, 6 Feb 2024 at 17:47, David Ansari
 wrote:
>
> Hi Robbie,
>
> Thanks a lot for your detailed reply.
> You already answered most of my questions.
> Are you aware of any AMQP 1.0 broker that implements the latest AMQP
> Management draft spec from 2019 (
> https://www.oasis-open.org/committees/download.php/65575/amqp-man-v1.0-wd16.docx
> )?
>
> It seems neither Azure Service Bus nor QPid implement it:
>
> Service Bus doesn't currently implement any of the core features of the
> > management specification
> >
> https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management
> <https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management>
>
> The AMQP protocols 0-8..0-10 allow for some management of Exchanges, Queue
> > and Bindings. This will be superseded by AMQP 1.0 Management. It is
> > suggested that new users favour the Management facilities provided by the
> > Web Console/REST API.
> >
> https://qpid.apache.org/releases/qpid-broker-j-9.1.0/book/Java-Broker-Management-Channel.html
>
>
> Using custom "management messages" as done in Artemis is probably a good
> approach for Artemis to support management operations over multiple
> protocols.
> The disadvantage is that there doesn't seem to be a standardization between
> different AMQP 1.0 clients and AMQP 1.0 servers on how to perform
> management operations.
> It seems while the idea of the draft AMQP management extension is great,
> I'm not aware of any AMQP 1.0 broker implementing it.
>
> I mainly ask because we are looking for "the best" (i.e a simple and
> interoperable) approach to dynamically create and delete queues, exchanges,
> and bindings via the AMQP 1.0 protocol in RabbitMQ.
>
> On Tue, Feb 6, 2024 at 1:41 PM Robbie Gemmell 
> wrote:
>
> > The invite I'll need to leave to someone else...
> >
> >
> > I'm not sure what your questions are, but Artemis does not implement
> > the "AMQP Management Version 1.0" extension though. I believe it was
> > only ever at working-draft stage, i.e there is actually no Version 1.0
> > yet really, and I dont think there has been any activity around it in
> > a number of years now.
> >
> > None of that is to say you can't manage Artemis over messaging using
> > AMQP though, just not that particular "AMQP Management" draft
> > extension.
> >
> >
> > https://activemq.apache.org/components/artemis/documentation/latest/management.html
> > has some details around using 'management messages' to manage the
> > broker. Although the doc is more aimed at the Core client originally,
> > the same general message-based request and  [temporary] reply-to queue
> > response-message based approach is generally applicable to the other
> > protocols the broker supports as well like AMQP.
> >
> > There is a management example that uses the JMS API client that can
> > presumably be adapted:
> >
> > https://github.com/apache/activemq-artemis-examples/blob/6958316d39b01f67add3c2f90a1bf75f62c39020/examples/features/standard/management/src/main/java/org/apache/activemq/artemis/jms/example/ManagementExample.java
> >
> > There is a test that does some basic management over

Re: Performance Testing Artemis ActiveMQ

[Robbie Gemmell]

Despite its claim of working with 'RabbitMQ or any AMQP message
broker' I'd expect that jmeter-amqp-plugin won't actually work with
many of them, including Artemis, since it indicates it is based around
rabbitmq-client and so is presumably using the AMQP 0-9-1 protocol
[with extensions] that RabbitMQ primarily uses. Artemis uses the later
AMQP 1.0 protocol standard which is quite different from the earlier
0-x protocols, and as such that client won't be able to connect to it.

On Thu, 4 Apr 2024 at 21:46, William Crowell
 wrote:
>
> Good afternoon/evening,
>
> I am looking for tools to performance test Apache Artemis.
>
> I have used the “artemis perf” performance test tool, but I am looking for a 
> tool outside of Artemis like Apache JMeter.
>
> I am aware of the JMeter AMQP Plugin 
> (https://github.com/aliesbelik/jmeter-amqp-plugin), but I cannot get it to 
> work with Artemis.  I have disabled security in Artemis, but I still get this 
> strange error:
>
> 2024-04-04 20:33:33,892 WARN  [org.apache.activemq.artemis.core.client] 
> AMQ212037: Connection failure to /xxx.xxx.xxx.xxx:49390 has been detected: 
> null [code=REMOTE_DISCONNECT]
>
> Anyone know of tools out there to performance test Apache Artemis?
>
> Regards,
>
> William Crowell
>
>
>
> This e-mail may contain information that is privileged or confidential. If 
> you are not the intended recipient, please delete the e-mail and any 
> attachments and notify us immediately.
>

Re: Stop - Unsubscribe

[Robbie Gemmell]

As covered at https://activemq.apache.org/contact (and described
earlier in this thread), to unsubscribe you would send an email to the
relevant mailing list email address:
users-unsubscr...@activemq.apache.org

On Tue, 14 May 2024 at 12:05, Soria, Adrian Manuel Arevalo
 wrote:
>
> Me 2. I would like to stop receiving these emails
>
> Adrian
>
> From: John Maurer 
> Date: Friday, 10 May 2024 at 16:07
> To: users@activemq.apache.org 
> Subject: Re: Stop - Unsubscribe
> I also would like to stop receiving these emails.
>
> jr.maurer@yahoo.comThank you, John Maurer
>
> On Thursday, May 9, 2024 at 10:41:54 AM CDT, Julian Coleman 
>  wrote:
>
>  Hi,
>
> > I also would like to stop receiving these emails.
> > Sadly I don't see any banners with instructions to do it.
>
> > If someone writes some quick instructions I can do it myself.
>
> I guess that modern mail readers hide the email headers, but messages sent
> to the list have a header line:
>
>   List-Unsubscribe: 
>
> Regards,
>
> Julian
>
> --
> Red Hat Czech, s.r.o.
> Brno
>
>
>
> 
> Denne e-posten og eventuelle vedlegg er beregnet utelukkende for den 
> institusjon eller person den er rettet til og kan vaere belagt med lovbestemt 
> taushetsplikt. Dersom e-posten er feilsendt, vennligst slett den og kontakt 
> Skatteetaten.
> The contents of this email message and any attachments are intended solely 
> for the addressee(s) and may contain confidential information and may be 
> legally protected from disclosure. If you are not the intended recipient of 
> this message, please immediately delete the message and alert the Norwegian 
> Tax Administration.

Re: [External] Re: UNSUBSCRIBE PLEASE

[Robbie Gemmell]

As covered at https://activemq.apache.org/contact, to unsubscribe you
would send an email to the relevant mailing list email address:
users-unsubscr...@activemq.apache.org

On Wed, 15 May 2024 at 13:29, Akoson Akotarh, Raymond
 wrote:
>
> Could someone please unsubscribe from this list? Can’t find any subscription 
> link. Thanks
>
> [https://res.cdn.office.net/assets/bookwithme/misc/CalendarPerson20px.png]
> Book time to meet with 
> me
>
> From: Sowjanya 
> Sent: Wednesday, May 15, 2024 1:44 AM
> To: users@activemq.apache.org
> Subject: [External] Re: Need help in upgrading activemq
>
> But Currently we are using activemq 5. 11. 2 wherein we have slf4j-api-1. 7. 
> 10. Similarly we have slf4j-api-1. 7. 10 in activemq 5. 12. 0 Not sure why 
> compatibility issues are coming. On Tue, May 14, 2024 at 7: 02 PM Matt 
> Pavlovich 
>
>
> But Currently we are using activemq 5.11.2 wherein we
>
> have slf4j-api-1.7.10. Similarly we have  slf4j-api-1.7.10 in activemq
>
> 5.12.0
>
> Not sure why compatibility issues are coming.
>
>
>
> On Tue, May 14, 2024 at 7:02 PM Matt Pavlovich 
> mailto:mattr...@gmail.com>> wrote:
>
>
>
> > This looks like a problem with slf4j logging library compatibility.
>
> >
>
> > -Matt
>
> >
>
> > > On May 13, 2024, at 11:20 PM, Sowjanya 
> > > mailto:sowjimedapat...@gmail.com>>
>
> > wrote:
>
> > >
>
> > > Hi
>
> > >
>
> > > We are trying to upgrade from activemq 5.11.2 to 5.12.0, New version of
>
> > > activemq is being reflected but unfortunately not able to access any
>
> > module
>
> > > in our application, Below are the logs we are getting.
>
> > >
>
> > > 2024-05-09 09:12:15,549 WARN  [com.adtran.mvc.view.ViewJSONServiceImpl]
>
> > > JSON View failed due to com.adtran.common.services.Ser
>
> > > viceSpecificException: 'java.lang.NoSuchMethodError:
>
> > > org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String
>
> > >  ;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V'
>
> > >
>
> > > Can you please help in sorting out this.
>
> > >
>
> > > Regards,
>
> > > Sowjanya
>
> >
>
> >

Re: Compatibility ActiveMQ Classic 5.18.x resource adapter and client with 6.x broker

[Robbie Gemmell]

You will likely have read
https://lists.apache.org/thread/pr2ty60xx54tm3tfnfb1k2hbrmvm59no or
the related Jira https://issues.apache.org/jira/browse/AMQ-9418

On Tue, 4 Jun 2024 at 10:54, Boeltl, Stefan
 wrote:
>
> Dear committers,
>
> I can't recall where I read about compatibility issues when using 5.18.x 
> clients/resource adapter with a 6.x broker (it was something to do with javax 
> vs. jakarta namespaces I think), that's why I post the following questions:
>
> 1. Are 5.18.x client (activemq-client, so javax namespace) and the resource 
> adapter compatible to a 6.x broker (all using Openwire)?
> 2. If not (because of javax/Jakarta clash): would it help to change all 
> clients to use activemq-client-jakarta (and what about the resource adapter - 
> any way to change to jakarta namespace here?)?
> 3. Any other thoughts for compatibility (besides moving to qpid and AMQP for 
> clients - unfortunately there's no XA enabled RA available here) if we need 
> to stay on Java 11 (= ActiveMQ 5.18.x) on client side?
>
> Thanks as always!
>
> Stefan
> The information contained in this message is proprietary and/or confidential. 
> If you are not the intended recipient, please: (i) delete the message and all 
> copies; (ii) do not disclose, distribute or use the message in any manner; 
> and (iii) notify the sender immediately. In addition, please be aware that 
> any message addressed to our domain is subject to archiving and review by 
> persons other than the intended recipient. Thank you.
> Message Encrypted via TLS connection

-
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Site activemq.apache.org unavailable

[Robbie Gemmell]

There is an issue with various projects websites just now, it is being
investigated.

On Wed, 10 Jul 2024 at 10:19, Alexander Milovidov  wrote:
>
> Hi All,
>
> Currently I cannot open any page on Apache ActiveMQ site: it returns 404
> not found. Tried from different locations.
> Is it ok?
>
>
> --
> Best regards,
> Alexander

-
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Site activemq.apache.org unavailable

[Robbie Gemmell]

Site is back up now.

On Wed, 10 Jul 2024 at 10:24, Robbie Gemmell  wrote:
>
> There is an issue with various projects websites just now, it is being
> investigated.
>
> On Wed, 10 Jul 2024 at 10:19, Alexander Milovidov  
> wrote:
> >
> > Hi All,
> >
> > Currently I cannot open any page on Apache ActiveMQ site: it returns 404
> > not found. Tried from different locations.
> > Is it ok?
> >
> >
> > --
> > Best regards,
> > Alexander

-
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Observations on _AMQ_LARGE_COMPRESSED have changed between 2.31.2 and 2.32.0

[Robbie Gemmell]

Give https://github.com/apache/activemq-artemis/commit/f56595b89b a
look, seems likely to relate.

It was included in 2.32.0 but erroneously referenced an earlier
released Jira from 2.29.0 and so isnt covered in the 2.32.0 release
notes (but is in the git commit report)

On Tue, 16 Jul 2024 at 14:24, Petr Kuzel
 wrote:
>
> Meanwhile I have been running integration tests with all Artemis
> versions between 2.31.2 and 2.35.0.
>
> The _AMQ_LARGE_COMPRESSED header observation changes
> between 2.31.2 and 2.32.0. Hope the narrowing helps.
>
> Reading 2.32.0 release notes, there is no evident match.
>
> Is it an intentional change between 2.31.2 and 2.32.0, please?
>
>
> --
>
>   Mr. Petr Kužel, Software Engineer
>
>
>
> 
> From: Petr Kuzel 
> Sent: Tuesday, July 16, 2024 10:53 AM
> To: users@activemq.apache.org 
> Subject: Observations on _AMQ_LARGE_COMPRESSED have changed between 2.31.2 
> and 2.35.0
>
>
> Hi the Apache Artemis Community,
>
> We send a failed message to an error queue via the CORE protocol with 
> compression.
> An idea is that the error queue messages should take as less resources as 
> possible
> till consumed or expired. It's a dependency on Artemis CORE protocol-specific 
> feature
> so we harnessed it just a little bit.
>
> Now, after speculatively upgrading Artemis dependency from 2.31.2 and 2.35.0
> (with no other changes) I can observe that the _AMQ_LARGE_COMPRESSED
> header is not present anymore on the failed message in the error queue.
> We use the _AMQ_LARGE_COMPRESSED header to deduce that the failed
> message is compressed in the error queue.
>
> First, is it an intentional change between 2.31.2 and 2.35.0, please?
>
>   Best regards
>   Petr
>
>
> --
>
>   Mr. Petr Kužel, Software Engineer
>
>   Eurofins International Support Services s.à r.l.
>
>   L-8399 Windhof
>
>

-
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [Ext] Re: Re: Artemis ClientID and shared topics

[Robbie Gemmell]

JMS 1 says that the named durable subscriptions are ClientID-scoped, you
needed a ClientID to use a named durable subscription (in practice many JMS
1 implementations did let you omit explicitly configuring a ClientID, so
long as you didnt try to use a durable subscription). It also says a given
ClientID can only be used by 1 Connection at a time. JMS 2 had to retain
those behaviours since full API compatibility was an aim, i.e only adding
new APIs and related behaviours.

I was not involved in JMS 2 so I can only speculate that they probably
decided to apply the 'if ClientID set, subscription is ClientID-scoped'
behaviour for both shared and non-shared subscriptions to continue the
prior behaviour and be consistent in that regard between the non-shared and
shared durable sub cases, and maybe to aid implementation, since they also
made non-shared and shared durable subscriptions both use the same/existing
ClientID-scoped namespace when a ClientID is set. However, ClientID was
also made expressly optional in JMS2, and when using the new shared
subscriptions behave such that there is a new distinct subscription space
for users who might want to share durable subscriptions across different
no-ClientID Connections at the same time. The non-durable shared
subscriptions similarly also have their own distinct spaces, with
ClientID-scope + without.

On Mon, 9 Sept 2024 at 13:51,  wrote:

> Hi Robbie,
>
> thank you for coming in on that.
> Yes  shared topics are specified as seen seen in JMS2. Bad for us.
> Why the clientID is needed in this context stays an unsolved mystery.
> The subsctiptionId (in other products called groupName) should be enough,
> right?
> But changing that is up to a later version of JMS.
>
> No matter - our customer wants to see, what application is connected to
> what broker.
> The ClientID would be great for that and the application name etc. is
> available.
>
> The ClientID is forced to be equal  for collaborating instances with
> shared topics.
> This is acceptable, because the connections have a different ID in their
> own right.
> Is there somewhere specified, that the ClientIDs have to be unique system
> wide?
> I didn't find a place and I doubt this is really possible.
> Leaving them all null is in fact "all equal", the opposite of unique ...
>
> Best Regards
>
> Herbert
>
> --
>
> *Herbert Helmstreit*
> Senior Software Engineer
>
> Phone: +49 941 / 7 83 92 36
> herbert.helmstr...@systema.com
>
> www.systema.com
>
> [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/>[image:
> Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: XING]
> <https://www.xing.com/pages/systemagmbh>
>
> SYSTEMA
> Systementwicklung Dipl.-Inf. Manfred Austen GmbH
>
> Manfred-von-Ardenne-Ring 6 | 01099 Dresden
> HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786
> Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO
>
> P Please check whether a printout of this e-mail is really necessary.
>
>
>
>
> Von:"Robbie Gemmell" 
> An:users@activemq.apache.org
> Datum:09.09.2024 12:16
> Betreff:[Ext] Re: Re: Artemis ClientID and shared topics
> --
>
>
>
> JMS 2 essentially outlined that shared named subscriptions on Connections
> with a ClientID are still ClientID-scoped (i.e can only be shared from that
> Connection), just as the existing non-shared named durable subscriptions
> were in JMS already. Additionally, JMS 2 also let you have shared named
> subscriptions on Connections without a ClientID, that could be shared with
> consumers on other similar Connections without a ClientID. This was how JMS
> 2 defined things ~12 years ago and so that is how things implementing it
> now work.
>
> The result of the JMS 2 additions was that there are 5 different effective
> topic subscription scopes/spaces (4 named, 1 not), and you can't access
> subscriptions in them all at the same time on the same Connection, since
> accessing some subs requires it has a specific ClientID, and others require
> that it does not. Personally, I would have considered a boolean arg on the
> new shared sub methods that indicated whether to scope the named shared
> subscription to the ClientID or not, but that is not what happened.
>
> On Fri, 6 Sept 2024 at 15:24,  wrote:
>
> > Hi Domenico,
> >
> > Thank you for pointing me there.
> > the spec says in other words the clients must have no id if they want to
> > use shared topics.
> > Or they have the same Client ID  which means the use the same connection,
> > because every connection needs a unique clientID witch can be tested
> q

Re: [DISCUSS] Using Travis CI for Artemis PR builds

[Robbie Gemmell]

I believe the mirrors in the apache github org have a shared resource
pool at Travis, while jobs for your personal forks run in the global
resource pool. Its not unusual for the latter to be quicker off the
mark, but even then its usually just seconds of difference.
Occasionally there can be a backlog from having really large jobs or
many jobs from other projects but typically its not been an issue for
long. Using Appveyor as well can help too as they tend not to be
backlogged at the same time and the additional env is useful in
itself.

Robbie

On 16 February 2018 at 16:00, Justin Bertram  wrote:
> I may have spoken too soon.  The UI on the Travis website apparently takes
> awhile to update or got out of sync or something.  The PR build looks to be
> taking around 25 minutes consistently which I think is pretty good.
>
>
> Justin
>
> On Thu, Feb 15, 2018 at 3:18 PM, Justin Bertram  wrote:
>
>> Initial results are not encouraging.
>>
>> I got Apache infrastructure to enable Travis CI builds [1] after which I
>> disabled the current Jenkins-based PR build and sent a PR with the
>> necessary .travis.yml file to trigger a Travis CI build [2].  I had also
>> enabled Travis CI builds on my own GitHub repo so the Travis CI build was
>> triggered on both the Apache PR as well as my own GitHub branch.  After an
>> hour I got an email saying the build for my personal GitHub branch
>> succeeded, but after almost an hour and a half the build for the Apache CI
>> failed for no clear reason.  Later I updated the PR branch and performed a
>> push -f to trigger more builds.  The build on my personal GitHub branch
>> finished without issue in about 20 minutes while the Apache PR build is
>> still waiting to actually start.
>>
>> This looks like a fail to me.
>>
>>
>> Justin
>>
>> [1] https://issues.apache.org/jira/browse/INFRA-16042
>> [2] https://github.com/apache/activemq-artemis/pull/1872
>>
>> On Tue, Feb 13, 2018 at 4:56 PM, Michael André Pearce <
>> michael.andre.pea...@me.com> wrote:
>>
>>> This is great idea! I get so frustrated with these environment issues.
>>> +100
>>>
>>> Some other advantages I could see we could implement if successful.
>>>
>>> run a Linux build and a macOS build eg to check bits like kqueue and or
>>> other os specific behaviours (aio fallback to nio)
>>>
>>> look to use appveyor for a windows build validation. (I’m thinking this
>>> validates bat files etc and ensures not Linux specific paths being used in
>>> code by mistake)
>>>
>>> Sent from my iPhone
>>>
>>> > On 14 Feb 2018, at 03:17, Justin Bertram  wrote:
>>> >
>>> > Over the last several months I've noticed that the Jenkins-based builds
>>> > used to validate GitHub pull-requests for Artemis are failing at a
>>> > significant rate for illegitimate reasons (e.g. environmental issues,
>>> > timing out because they're too slow, etc.) or not being run at all.
>>> Even
>>> > as I type this there are 4 PR builds listed on
>>> https://builds.apache.org/
>>> > which have been waiting for hours.
>>> >
>>> > I'd like to solve this problem so we have relatively quick & reliable PR
>>> > builds.  I'm vaguely familiar with Travis CI, and I know other Apache
>>> > projects use it for PR builds.  I think it would be worth investigating
>>> > whether or not it would solve our problem.  What do you guys think?
>>> Does
>>> > anybody in the community have experience with Travis CI?
>>> >
>>> >
>>> > Justin
>>>
>>
>>

Re: Change minLargeMessageSize on Artemis

[Robbie Gemmell]

AMQP messages arent classed as being 'large' or not at a protocol
level, but rather just messages which can be sent using 1 or more
message-transfer frames as needed or appropriate to the situation.
Messages can be split into multiple frames based on the servers
advertised max frame size, which it can use use to govern clients
behaviour, or maybe the clients own abilities/needs. The combined
frame payloads on receipt then represent the complete message,
whatever its size.

As I understand it, Artemis internally treats AMQP messages as 'large
messages' currently if their encoded size is above the smaller of the
journals configured 'journal-buffer-size' and 'journal-file-size'
settings.

Robbie

On 7 May 2018 at 03:50, Justin Bertram  wrote:
>> But I don't understand why a client should decide on how a message should
> be treated on the server.
>
> Because "large" message support as originally conceived for the "core"
> protocol (the foundational protocol used by Artemis) involves (at least in
> part) clients *streaming* messages in chunks to the broker. The broker has
> no influence on how clients send messages to the broker - whether that be
> all at once or broken up into chunks which are more manageable from a
> memory perspective. Therefore, it's up to the client to decide that.
>
> Non-core protocols (e.g. AMQP) have limited "large" message support.
>
>
> Justin
>
> On Sun, May 6, 2018 at 5:58 PM, z94joma  wrote:
>
>> Hi
>>
>> Thanks for your answer.
>>
>> I find the answer a bit strange. It probably is correct though.
>>
>> But I don't understand why a client should decide on how a message should
>> be
>> treated on the server. As in my case the client can actually crash my
>> consumer (As it cannot read large messages if put in large message folder.)
>>
>> But I will try your suggestions during the week and let everyone know.
>>
>> /Magnus
>>
>>
>>
>>
>>
>> --
>> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
>> f2341805.html
>>

Re: [ANNOUNCE] ActiveMQ Artemis 2.6.2 Released

[Robbie Gemmell]

Thanks for mentioning, it looks like some of the final release steps
weren't entirely completed. I've added a 2.6.2 release notes page.

Robbie

On 25 June 2018 at 07:28, Stefaniuk, Marcin
 wrote:
> Release notes are a dead link.
>
>
> -Original Message-
> From: Clebert Suconic [mailto:clebert.suco...@gmail.com]
> Sent: 23 June 2018 16:28
> To: d...@activemq.apache.org; users@activemq.apache.org
> Subject: [ANNOUNCE] ActiveMQ Artemis 2.6.2 Released
>
> I'm pleased to announce the release of ActiveMQ Artemis 2.6.2
>
>
> Downloads are now available at:
> http://activemq.apache.org/artemis/download.html
>
>
> For a complete list of updates:
> http://activemq.apache.org/artemis/release-notes-2.6.2.html
>
>
> This was a maintenance and small release, the release notes should be
> enough to see the payload on this release.
>
>
>
> Many thanks for all the contributors to this release.
>
>
> ===
> Please access the attached hyperlink for an important electronic 
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ===

Re: Simple question on AMQP 1.0 protocol support

[Robbie Gemmell]

On 20 July 2018 at 17:49, dbeavon  wrote:
> If a client and broker implement the AMQP 1.0 standard spec, then they should
> be able to interoperate, right?  IE it is the standard that matters more
> than the particular version/revision of the client code.
>
> I'm asking because redhat distributes v.1.1.8 of the amqpnetlite client and
> I can get a much improved version 2.1.2 out of nuget
> (https://www.nuget.org/packages/AMQPNetLite/).  Both implement AMQP 1.0.  I
> would like to user the newer one if possible.

You appear to be overlooking newer distributions of that client from
Red Hat, as the current linked client downloads are 2.1.x based.

>
> I understand that I won't get an official response from redhat on these
> forums.  But I just want to make sure that I'm accurate in thinking that any
> client should work if it properly implements the standard.  I suspect if I
> ran into a bug then redhat would ask me to repro it on 1.1.8 before they
> would offer formal support.
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: [Artemis 2.6.2] AMQP messages going to expiry queue, redelivery off that queue is failing

[Robbie Gemmell]

Tim and I had an initial look at this, and can see generally where the
broker is internally corrupting things on send, though not yet the
full picture how it gets there or what to do about it. The expiration
is likely to be key, one difference with the non-transacted case is
actually going to be because its using recover() which the client
performs locally.

Robbie

On Wed, 29 Aug 2018 at 06:23, Dan Langford  wrote:
>
> ok i wrote 3 test files. I don't know the best way to get them to you
> easily. hopefully a Gist is ok.
> https://gist.github.com/danlangford/071e738225ec0c68dd470816b977499b
>
> you can copy those 3 files straight to
> ./tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp
>
> The test JMSTransactedRedeliveryTest::testAMQPProducerAMQPConsumer proves
> that a transacted client can .rollback() a handful of times and still be
> able to consume the redelivered message later on.
>
> The test JMSTransactedRedeliveryBugTest::testAMQPProducerAMQPConsumer shows
> that if a message had been expired and now a transacted client is
> attempting to consume it the client only has 2 chances before the broker
> starts sending the message in a way that will not parse correctly
>
> The test JMSNonTransactedRedeliveryBugTest::testAMQPProducerAMQPConsumer shows
> that if a message had been expired a non-transacted client has no troubles
> reliably accessing the redelivered message from broker
>
>
> as you can tell i am mostly concerned about AMQP->AMQP for my use case.
> some of those other combos are failing some of these tests in other ways.
> naturally you can address those as you see fit but for my client the
> AMQP->AMQP is a roadblocker.
>
>
> let me know if you can determine why the broker is sending an extra null
> character in the payload on the third time the messages attempts delivery.
> maybe we are doing something incorrectly.
>
>
> This has been more of an issue than i thought due to the fact that Spring
> default to enabling transactions. in all of my initial tests i couldn't
> reproduce it because i prefer the straight simplified jms api from 2.0 and
> that defaults to sessions not being transacted. that being said nearly all
> of my clients prefer using Spring Boot autoconfigurer and other spring
> pieces which happen to default to transacted sessions.  i can now have some
> of them workaround but others of them are requiring the transaction.
>
>
> also as a reminder and for context here is a link to the initial
> conversation i had with the Qpid Jms Client devs who pointed out to me the
> erroneous null character in the message transfer from the broker:
> https://lists.apache.org/
> thread.html/b1fd9c09a1f66f5529601a8651fbb96585c011b22bbd84e07c4f23b1@%3Cusers.qpid.apache.org%3E
>
>
> thank you so much for your time
>
> On Tue, Aug 14, 2018 at 1:19 PM Timothy Bish  wrote:
>
> > On 08/13/2018 07:12 PM, Dan Langford wrote:
> > > some of my users are attempting a pattern to deduplicate messages based
> > on
> > > a time window instead of a fixed amount of space (a duplicate id cache)
> > >
> > > so far the concept has been working very well. So they send their AMQP
> > > messages (qpid-jms-client) into a Last Value Queue with an appropriate
> > > identifier in the _AMQ_LVQ_NAME. They also set a TimeToLive on the
> > message
> > > that is essentially the lag they will allow as they want to wait for
> > > possible duplicates. If any duplicates come in the Last Value Queue
> > > behavior is replacing the older message with the newer message until the
> > > expiration. expired messages are delivered to the preconfigured expiry
> > > queue where their application is listening. This is not perfect but its
> > not
> > > intended to be. Its just intended to reduce additional unnecessary
> > > processing and they understand this is not a guarantee. It really helps
> > > with a system that produces messages in a way that has flurries of
> > > "notifications" about the same assetID over and over again.
> > >
> > > BUT where we are seeing is a problem is when we are consuming from the
> > > queue used to hold expired messages and we toss some exception and the
> > > message needs to be redelivered. the first time or two the message is
> > > redelivered it is delivered OK. But when the JMSXDeliveryCount is about 3
> > > or 4 (we use redelivery delay and multipliers to spread these out) our
> > > qpid-jms-client stops being able to read the messages.
> > >
> > > we were only able to reproduce this when an AMQP message expired onto the
> > > queue. (expired from a LVQ in case that is relevant). if we place the
> > > message directly on a queue and test different exception and redelivery
> > > scenarios we cannot reproduce this behavior.
> > >
> > > i enable the qpid-jms-client frame logging (via env variable
> > > PN_TRACE_FRM=true) and i saw that in the situation when the client code
> > > cannot access the payload, even though the broker WAS still sending the
> > > payload.

Re: [Artemis 2.6.2] AMQP messages going to expiry queue, redelivery off that queue is failing

[Robbie Gemmell]

To confirm, the broker issue had nothing to do with use of
transactions specifically. You only saw any variation there due to
difference in client behaviour altering the overall situation in the
limited test.

Master and 2.6.x now have some fairly different message handling in
this area, so you should try whichever is more appropriate to you.

On Sun, 14 Oct 2018 at 17:41, Dan Langford  wrote:
>
> Just for the record: even though we could easily recreate this problem
> using transactions, and our initial “workaround” involved not using
> transactions, we have recently seen this issue when no transactions where
> involved.
>
> Reading through the Jira description it looks like this is not specifically
> about transactions so I am hopeful that the fix will address even our
> current issues.
>
> Since our users are now focusing on this again I will probably build from
> master to test the fix
>
>
>
> On Tue, Sep 11, 2018 at 4:46 PM Dan Langford  wrote:
>
> > Thank you guys so much!
> > On Tue, Sep 11, 2018 at 2:50 PM Timothy Bish  wrote:
> >
> >> On 08/30/2018 07:10 PM, Dan Langford wrote:
> >> > thanks for looking into this. what is the proper way to force for
> >> testing a
> >> > redelivery that goes back to the broker without transactions? its
> >> probably
> >> > like killing the session or connection. that would be if we wanted to
> >> test
> >> > if non-transacted redeliveries were getting corrupted
> >>
> >> The issue has been identified and fixed, should appear in the next
> >> release.
> >> https://issues.apache.org/jira/browse/ARTEMIS-2082
> >>
> >> >
> >> > we have a lot of people using spring-jms and as i look in the spring
> >> code...
> >> >
> >> https://github.com/spring-projects/spring-framework/blob/master/spring-jms/src/main/java/org/springframework/jms/listener/AbstractMessageListenerContainer.java
> >> > looking at doExecuteListener and rollbackOnExceptionIfNecessary
> >> > it looks like if its transacted they try to rollback() and if its
> >> > client_ack they try recover(). they probably dont handle auto_ack
> >> because
> >> > that was acked immediately?
> >> >
> >> > speaking of this what is an appropriate way to NACK a message when using
> >> > Client Acknowledgemnt and a JMS messageHandler? is it simply to reach
> >> the
> >> > end of the method execution without having called message.acknowledge()
> >> or
> >> > would it be appropriate to throw a RuntimeException (since i cannot
> >> throw a
> >> > checked Exception out of an implementation of
> >> javax.jms.MessageListener) ?
> >> >
> >> > On Thu, Aug 30, 2018 at 8:38 AM Robbie Gemmell <
> >> robbie.gemm...@gmail.com>
> >> > wrote:
> >> >
> >> >> Tim and I had an initial look at this, and can see generally where the
> >> >> broker is internally corrupting things on send, though not yet the
> >> >> full picture how it gets there or what to do about it. The expiration
> >> >> is likely to be key, one difference with the non-transacted case is
> >> >> actually going to be because its using recover() which the client
> >> >> performs locally.
> >> >>
> >> >> Robbie
> >> >>
> >> >> On Wed, 29 Aug 2018 at 06:23, Dan Langford 
> >> wrote:
> >> >>> ok i wrote 3 test files. I don't know the best way to get them to you
> >> >>> easily. hopefully a Gist is ok.
> >> >>> https://gist.github.com/danlangford/071e738225ec0c68dd470816b977499b
> >> >>>
> >> >>> you can copy those 3 files straight to
> >> >>>
> >> >>
> >> ./tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp
> >> >>> The test JMSTransactedRedeliveryTest::testAMQPProducerAMQPConsumer
> >> proves
> >> >>> that a transacted client can .rollback() a handful of times and still
> >> be
> >> >>> able to consume the redelivered message later on.
> >> >>>
> >> >>> The test JMSTransactedRedeliveryBugTest::testAMQPProducerAMQPConsumer
> >> >> shows
> >> >>> that if a message had been expired and now a transacted client is
> >> >>> attempting to consume it the client only has 2 chances before the
> >> broker
> >> >

Re: Artemis GitHub repo archived?

[Robbie Gemmell]

I also asked for assistance in infras chat but as expected though its
a bit quiet in there just now, likely need to wait until a little
later in the day.

Robbie

On Tue, 26 Mar 2019 at 08:57,  wrote:
>
> This is a mistake.
>
>
>
>
> The PMC voted to deprecate apollo sub project. And i raised a ticket with 
> infra to do this. But whislt the title of the ticket was for apollo i 
> accidentally put artemis git in the comment (copy error). Confusing infra. I 
> have already messaged infra on the same ticket.
>
>
>
>
> This is entirely my mistake. Artemis is most definitely alive
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Tue, Mar 26, 2019 at 8:47 AM +,  wrote:
>
>
>
>
>
>
>
>
>
>
> Hi,
> I just saw the message "This repository has been archived by the owner. It is 
> now read-only." on https://github.com/apache/activemq-artemis 
> (https://github.com/apache/activemq-artemis) and since I didn't see an 
> announcement in the mailing list I wanted to ask if this was a mistake or if 
> you no more accept PRs via github.
>
> Thanks,
> Jo
>
>
>
>
>

Re: Artemis GitHub repo archived?

[Robbie Gemmell]

I brought it to attention of Daniel from the infra team once he was
around on chat and he fixed thigns up swiftly, the repo is now back in
action.

Robbie

On Tue, 26 Mar 2019 at 09:46,  wrote:
>
> Thanks Robbie
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Tue, Mar 26, 2019 at 9:43 AM +, "Robbie Gemmell" 
>  wrote:
>
>
>
>
>
>
>
>
>
>
> I also asked for assistance in infras chat but as expected though its
> a bit quiet in there just now, likely need to wait until a little
> later in the day.
>
> Robbie
>
> On Tue, 26 Mar 2019 at 08:57,  wrote:
> >
> > This is a mistake.
> >
> >
> >
> >
> > The PMC voted to deprecate apollo sub project. And i raised a ticket with 
> > infra to do this. But whislt the title of the ticket was for apollo i 
> > accidentally put artemis git in the comment (copy error). Confusing infra. 
> > I have already messaged infra on the same ticket.
> >
> >
> >
> >
> > This is entirely my mistake. Artemis is most definitely alive
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Mar 26, 2019 at 8:47 AM +,  wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> > I just saw the message "This repository has been archived by the owner. It 
> > is now read-only." on https://github.com/apache/activemq-artemis 
> > (https://github.com/apache/activemq-artemis) and since I didn't see an 
> > announcement in the mailing list I wanted to ask if this was a mistake or 
> > if you no more accept PRs via github.
> >
> > Thanks,
> > Jo
> >
> >
> >
> >
> >
>
>
>
>
>

Re: Artemis/AMQP Scheduled Delay

[Robbie Gemmell]

On the wire, the key in the message annotations map needs to be of
'symbol' type rather than string, with the delivery time value a long.
I havent tried this but for the former I believe something like
"symbol('x-opt-delivery-time')" would be what you need.

On Thu, 9 May 2019 at 16:34, Neil Dunbar
 wrote:
>
> Hi all,
>
> I’m having a bit of trouble using the scheduled delivery function in Artemis 
> (2.6.4) in an AMQP protocol, via the Qpid-Proton Python library.
>
> From what I can tell, this should work (from the simple sender example in the 
> Proton repo)
>
> from datetime import datetime as dt, timezone as tc
>
> deltime = int(dt.utcnow().replace(tzinfo=tz.utc).timestamp() * 
> 1000.0) + 12
> anns = {'x-opt-delivery-time' : deltime}
> while event.sender.credit and self.sent < self.total:
> msg = Message(id=(self.ts * 100 + self.sent+1), 
> body={'sequence':(self.sent+1)}, annotations=anns)
>
> event.sender.send(msg)
> self.sent += 1
>
> The messages are properly queued, but delivered instantly.
>
> I’m guessing that there’s some property which needs to be set at the broker 
> level, but not quite sure what.
>
> No doubt there’s some obvious setting that I’m missing, so would appreciate 
> the help.
>
> Cheers,
>
> Neil

Re: Non_persistent messages and qpid-jms-client-0.20.0.jar or higher.

[Robbie Gemmell]

FYI, the Qpid JMS 0.42.0 release contains a client change that should
help avoid the broker bug. It should sync to Maven Central in the next
hour or two.

On Sun, 5 May 2019 at 16:30, Patrick Vansevenant
 wrote:
>
>
> Thank you for the quick response, Tim.
>
> I'm indeed confronted with the same problem as described in
> https://issues.apache.org/jira/browse/AMQ-7189.
>
> The JMS transformer is, as you indicated, the perfect workaround.
>
> Patrick
> ---
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Broken links relating to Destination docs in Java

[Robbie Gemmell]

Your wiki updates wont actually make it to the website, as the wiki
isnt used for the site anymore.

The website source and generated content are now maintained in a git
repository at https://gitbox.apache.org/repos/asf/activemq-website.git
, and mirror https://github.com/apache/activemq-website which can be
used to raise PRs. Updates to the generated 'content' dir are synced
to the live site immediately once pushed.

I've updated the links to remove the 5.8.0 and fix their anchors in
https://github.com/apache/activemq-website/commit/f86836048b9eb662c5607b52ca3afc9249bce106

Robbie

On Mon, 14 Oct 2019 at 07:19, Tim Bain  wrote:
>
> I've updated the links; I'm not sure exactly how quickly the updates
> propagate out to the live site, but hopefully they'll be there within a day.
>
> Thanks for bringing it to our attention.
>
> Tim
>
> On Wed, Oct 2, 2019 at 1:01 PM Justin Bertram  wrote:
>
> > It looks like the directory got moved during the migration to the new site
> > and those links didn't get updated. Take out the "/5.8.0" out of the
> > failing URLs and should fix it until the site is updated.
> >
> > Sorry for the trouble!
> >
> >
> > Justin
> >
> > On Wed, Oct 2, 2019 at 1:32 PM Luc Hebert 
> > wrote:
> >
> > > Hi there,
> > > I'm doing some research relating to the following topic located here:
> > > https://activemq.apache.org/how-can-i-see-what-destinations-are-used
> > >
> > > However most links on this page are broken.  Any alternate URLs for these
> > > sections available?
> > >
> > > Thank you!
> > >
> > > *---*
> > >
> > > *Luc Hebert*
> > > Software Developer - Web Team Lead | Symboticware Incorporated
> > >
> > > *Phone: (800) 519-5496 ext. 118*
> > >
> > > Website: www.symboticware.com
> > >
> >

Re: Creating a temporary queue from AMQP

[Robbie Gemmell]

The way to create a temp queue is to attach a receiving link with a
source that sets 'dynamic' to true and with no address, instructing a
server to create a dynamic/temporary node. The 'reply' attach source
then contains its address (assuming success and that there is then a
source).

Robbie

On Mon, 13 Jan 2020 at 10:32, Dirkjan Ochtman  wrote:
>
> Hi there,
>
> I'm still working on my reimplementation of an AMQP 1.0 client in Rust. I
> have implemented all the bits that are required to send a message to my
> target application, but I'm having trouble attaching to the second link
> that is supposed to be used to receive the responses to the messages. I'm
> using Artemis 2.6.2 here (I know this is a bit dated -- that's what comes
> with the vendor application).
>
> The application I'm targeting usually uses Core messages to do RPC, but it
> accepts AMQP messages as well, so it could be that there is a mismatch here
> between how things are set up.
>
> When using Core, I see that ServerSessionPacketHandler triggers on a packet
> with type -12 to create the queue with a well-defined name, which in the
> end dispatches to ServerSessionImpl.createQueue() with temporary = true and
> durable = false. This is the behavior I'm seeking to replicate. However,
> all my attempts to create to a temporary non-durable queue by attaching to
> it with AMQP seem to be failing so far.
>
> With my new AMQP client, I try to create the response queue by attaching to
> it with source address = . This lets me end up in
> ProtonServerSenderContext.initialise() by way of
> AMQPSessionContext.addSender(). However, this throws a permission error
> (AMQ119213, my user does not have permission for CREATE_DURABLE_QUEUE).
> This is surprising to me because I leave the "durable" field as default,
> which should mean to default to no durability. It seems to happen because
> AMQPSessionCallback.queueQuery() calls (through some indirection)
> ServerSessionImpl.createQueue() with durable = true. I have to admit to
> being confused about the distinction between address and queue in
> initialise(), so I also tried with
> "::" as the source address to see
> if I could trigger a different code path in initialise(). This results in a
> QUEUE_DOES_NOT_EXIST error.
>
> This is my attach message:
>
> [0, 0, 0, 133, 2, 0, 0, 0, 0, 83, 18, 208, 0, 0, 0, 117, 0, 0, 0, 14, 161,
> 37, 114, 112, 99, 46, 99, 108, 105, 101, 110, 116, 46, 118, 120, 100, 105,
> 114, 46, 49, 50, 53, 52, 50, 57, 54, 53, 55, 53, 55, 48, 52, 57, 48, 48,
> 56, 51, 52, 48, 82, 1, 65, 64, 64, 0, 83, 40, 208, 0, 0, 0, 53, 0, 0, 0,
> 11, 161, 37, 114, 112, 99, 46, 99, 108, 105, 101, 110, 116, 46, 118, 120,
> 100, 105, 114, 46, 49, 50, 53, 52, 50, 57, 54, 53, 55, 53, 55, 48, 52, 57,
> 48, 48, 56, 51, 52, 48, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64,
> 64, 64, 64, 64, 64]
>
> Thanks in advance,
>
> Dirkjan

Re: [ANNOUNCE] ActiveMQ Artemis 2.13.0 Released

[Robbie Gemmell]

On Tue, 26 May 2020 at 18:16, Clebert Suconic  wrote:
>
> I'm pleased to announce the release of ActiveMQ Artemis 2.13.0
>
> Downloads are now available at:
> http://activemq.apache.org/artemis/download.html
>
>
> This version has some major improvements on AMQP Performance. We
> performed extensive tests with AMQP and found a few minor changes that
> made a huge impact in performance, especially around flow control.
>
> There are other improvements that you can follow through the release notes:
>
> http://activemq.apache.org/components/artemis/download/release-notes-2.13.0
>
>
> Many thanks for all the contributors to this release.

The release is available from the website as above but there looks to
have been an issue with it being synced to Maven Central and so it
isn't available there yet, though it is in the ASF maven repo. I've
reported the issue to ASF Infra to look into.

Robbie

Re: [ANNOUNCE] ActiveMQ Artemis 2.13.0 Released

[Robbie Gemmell]

On Wed, 27 May 2020 at 10:59, Robbie Gemmell  wrote:
>
> On Tue, 26 May 2020 at 18:16, Clebert Suconic  
> wrote:
> >
> > I'm pleased to announce the release of ActiveMQ Artemis 2.13.0
> >
> > Downloads are now available at:
> > http://activemq.apache.org/artemis/download.html
> >
> >
> > This version has some major improvements on AMQP Performance. We
> > performed extensive tests with AMQP and found a few minor changes that
> > made a huge impact in performance, especially around flow control.
> >
> > There are other improvements that you can follow through the release notes:
> >
> > http://activemq.apache.org/components/artemis/download/release-notes-2.13.0
> >
> >
> > Many thanks for all the contributors to this release.
>
> The release is available from the website as above but there looks to
> have been an issue with it being synced to Maven Central and so it
> isn't available there yet, though it is in the ASF maven repo. I've
> reported the issue to ASF Infra to look into.
>

The release has now been synced to Maven Central.

Re: [DISCUSS] Apache Jira & GitHub integration

[Robbie Gemmell]

JIRAs have still been getting updated with PR opening/comment/closing,
just maybe not in entirely the same way as old. The PR comment syncing
changed to being added as JIRA work-log items by default a long long
time ago, and remained that way unless you asked for them to instead
be commented again. This was way before January and so had nothing to
do with the .asf.yaml. addition, which couldn't actually control that
setting at the time.

The JIRA links look to be the main difference (I hadn't noticed it, I
never really use them as-things-happen since there are emails and
work-log items for the updates, but I agree it is a nice touch for
later cross reference). It's possible that it was affected by the
.asf.yaml addition, though you couldn't configure that setting there
until just April it seems, and even then via a different config
section than the file used, so it would still be a little odd. I think
infra maybe just steered you that way since it is the new way of doing
it, and if it worked then it would save them looking into whatever was
broken ;)

Robbie

On Thu, 6 Aug 2020 at 20:52, Justin Bertram  wrote:
>
> I think I got it sorted. Apache infra pointed me to this page [1] which
> pointed me here [2]. I took the previous settings and applied them to the
> Artemis repo's .asf.yaml file.
>
> It looks like this was inadvertently broken by this commit [3] back in
> January.
>
>
> Justin
>
> [1]
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Notificationsettingsforrepositories
> [2] https://gitbox.apache.org/schemes.cgi?activemq-artemis
> [3]
> https://github.com/apache/activemq-artemis/commit/038dfe88817f793993b3c42f6f677b7615fb66de
>
> On Thu, Aug 6, 2020 at 2:37 PM Justin Bertram  wrote:
>
> > Is it me or has anyone else noticed that the integration between Apache
> > Jira and GitHub has stopped working? Links for corresponding pull-requests
> > on GitHub used to be created on Jiras and comments on the PR used to be
> > copied to the Jira as well. This stopped working a while back (I'm not sure
> > of the exact date).
> >
> > I'm trying to work with Apache infra to get the situation sorted out, but
> > if anybody has any info the meantime please let me know.
> >
> >
> > Justin
> >

Re: artemis.cmd run Found unexpected parameters: [run]

[Robbie Gemmell]

The below suggests you are trying to run the initial instal etc tool
script, rather than a broker instance script used to start a specific
broker. Did you create a broker instance as detailed in the readme
(see the create command listed in the help output below) ? That
creates a further script used for starting the broker, and prints out
some example commands for using it.

On Mon, 28 Sep 2020 at 07:34, Jürgen Weber  wrote:
>
> Hi,
>
> I tried to run artemis as in the README.html
>
> How should I start the broker?
>
> C:\java\apache-artemis-2.15.0\bin>artemis.cmd run
> Found unexpected parameters: [run]
>
> usage: artemis  []
>
> The most commonly used artemis commands are:
> address Address tools group (create|delete|update|show)
> (example ./artemis address create)
> browser It will browse messages on an instance
> check   Check tools group (node|queue) (example ./artemis check node)
> consumerIt will consume messages from an instance
> create  creates a new broker instance
> datadata tools group (print) (example ./artemis data print)
> helpDisplay help information
> maskmask a password and print it out
> migrate1x   Migrates the configuration of a 1.x Artemis Broker
> producerIt will send messages to an instance
> queue   Queue tools group (create|delete|update|stat|purge)
> (example ./artemis queue create)
>
> See 'artemis help ' for more information on a specific command.
>
>
> C:\java\apache-artemis-2.15.0\bin>java -version
> openjdk version "11.0.7" 2020-04-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)

Re: Log rotation - remove files older than 5 days

[Robbie Gemmell]

I dont know if there is already a simple a way to use Logback
directly/indirectly (without e.g implementing such a handler), but in
terms of log rotation I see from etc/logging.properties that the
config shows 
handler.FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
is the default handler used, and having a quick google and peek at the
source tree at 
https://github.com/jboss-logging/jboss-logmanager/blob/2.1.10.Final/src/main/java/org/jboss/logmanager/handlers/PeriodicRotatingFileHandler.java#L130
suggests that it picks the smallest element (year, month, week, etc)
from the supplied suffix as its rotation period. While there I spotted
there looks to be an extended version of the handler for doing
size-based rolling too that also incorporates a 'max backups' ability
https://github.com/jboss-logging/jboss-logmanager/blob/2.1.10.Final/src/main/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandler.java#L207,
which may be of interest to you...though I guess you might also need
to e.g set a large file size to make it more likely only the period
influences the rollover.


On Fri, 18 Sep 2020 at 13:11, BARSZCZ, KRZYSZTOF
 wrote:
>
> Hi,
> We are trying to achieve that only Artemis logs from the last 5 days will be 
> kept (older logfiles should be removed). The functionality provided by 
> RollingFileAppender from logback 
> http://logback.qos.ch/manual/appenders.html#RollingFileAppender is completely 
> sufficient (produce new file every day, set history size to 5). Could you 
> provide some tips how to use this class or achieve similar functionality? The 
> documentation 
> https://activemq.apache.org/components/artemis/documentation/latest/logging.html
>  says the handler has to extend `java.util.logging.Handler`, which 
> RollingFileAppender doesn’t. Is there a way to configure Artemis to e.g. use 
> slf4j and logback?
>
> Best wishes,
> Krzysztof Barszcz
>
>
>
> Lufthansa Systems Poland sp. z o.o., Siedziba: Aleja Grunwaldzka 415, 80-309 
> Gdańsk, Prezes Zarządu: Dariusz Przywara
> Sad Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego 
> Rejestru Sadowego, nr KRS: 083575, NIP: 583-24-68-348, Regon: 191499280 
> kapitał zakładowy 200.000 zł.
> ---
> Lufthansa Systems Poland Sp. z o.o., Corporate Headquarters: Aleja 
> Grunwaldzka 415, 80-309 Gdansk, President of the Management Board: Dariusz 
> Przywara
> Registration: the District Court of Gdansk-Polnoc in Gdansk, VII Commercial 
> Department of the National Court Register, KRS no: 083575, VAT UE no: PL 
> 583-24-68-348, REGON no: 191499280, Initial capital 200.000 PLN
>

Re: artemis.cmd run Found unexpected parameters: [run]

[Robbie Gemmell]

You did create one yes, however you then didn't actually go on to use
it, and instead tried issuing the run command to the base script
again, which doesnt support it as it then indicates.

Note the output during creation includes some example commands for
running the broker instance, which uses a different script found
within the created instance dir.

E.g since you created an instance in a dir named "test" directly
within the extracted bin dir, your output lists example:
"C:\java\apache-artemis-2.15.0\bin\test\bin\artemis" run

(Thats presumably missing a .cmd extension for use on Windows)

Robbie

On Mon, 28 Sep 2020 at 12:46, Jürgen Weber  wrote:
>
> I think I created an instance. The complete journal:
>
> C:\java\apache-artemis-2.15.0\bin>dir
>  Datenträger in Laufwerk C: ist Windows
>  Volumeseriennummer: F4C1-7A8D
>
>  Verzeichnis von C:\java\apache-artemis-2.15.0\bin
>
> 24.08.2020  20:45  .
> 24.08.2020  20:45  ..
> 24.08.2020  20:26 2.713 artemis
> 24.08.2020  20:26 1.945 artemis.cmd
> 24.08.2020  20:45  lib
>2 Datei(en),  4.658 Bytes
>3 Verzeichnis(se), 118.109.212.672 Bytes frei
>
> C:\java\apache-artemis-2.15.0\bin>artemis.cmd create test
> Creating ActiveMQ Artemis instance at: C:\java\apache-artemis-2.15.0\bin\test
>
> --user: is a mandatory property!
> Please provide the default username:
> test
>
> --password: is mandatory with this configuration:
> Please provide the default password:
>
>
> --allow-anonymous | --require-login: is a mandatory property!
> Allow anonymous access?, valid values are Y,N,True,False
> Y
>
> Auto tuning journal ...
> done! Your system can make 3,73 writes per millisecond, your
> journal-buffer-timeout will be 268000
>
> You can now start the broker by executing:
>
>"C:\java\apache-artemis-2.15.0\bin\test\bin\artemis" run
>
> Or you can setup the broker as Windows service and run it in the background:
>
>"C:\java\apache-artemis-2.15.0\bin\test\bin\artemis-service.exe" install
>"C:\java\apache-artemis-2.15.0\bin\test\bin\artemis-service.exe" start
>
>To stop the windows service:
>   "C:\java\apache-artemis-2.15.0\bin\test\bin\artemis-service.exe" stop
>
>To uninstall the windows service
>   "C:\java\apache-artemis-2.15.0\bin\test\bin\artemis-service.exe" 
> uninstall
>
> C:\java\apache-artemis-2.15.0\bin>artemis.cmd run
> Found unexpected parameters: [run]
>
> usage: artemis  []
>
> The most commonly used artemis commands are:
> address Address tools group (create|delete|update|show)
> (example ./artemis address create)
> browser It will browse messages on an instance
> check   Check tools group (node|queue) (example ./artemis check node)
> consumerIt will consume messages from an instance
> create  creates a new broker instance
> datadata tools group (print) (example ./artemis data print)
> helpDisplay help information
> maskmask a password and print it out
> migrate1x   Migrates the configuration of a 1.x Artemis Broker
> producerIt will send messages to an instance
> queue   Queue tools group (create|delete|update|stat|purge)
> (example ./artemis queue create)
>
> See 'artemis help ' for more information on a specific command.
>
>
> C:\java\apache-artemis-2.15.0\bin>java -version
> openjdk version "11.0.7" 2020-04-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)
>
>
> Am Mo., 28. Sept. 2020 um 13:07 Uhr schrieb Robbie Gemmell
> :
> >
> > The below suggests you are trying to run the initial instal etc tool
> > script, rather than a broker instance script used to start a specific
> > broker. Did you create a broker instance as detailed in the readme
> > (see the create command listed in the help output below) ? That
> > creates a further script used for starting the broker, and prints out
> > some example commands for using it.
> >
> > On Mon, 28 Sep 2020 at 07:34, Jürgen Weber  wrote:
> > >
> > > Hi,
> > >
> > > I tried to run artemis as in the README.html
> > >
> > > How should I start the broker?
> > >
> > > C:\java\apache-artemis-2.15.0\bin>artemis.cmd run
> > > Found unexpected parameters: [run]
> > >
> > > usage: artemis  []
> > >
> > > The most commonly used artemis commands are:
> > > address Address tools gro

Re: Understanding of Artemis multicastPrefix in AMQP address prevents the transfer of historical and pending messages of queue

[Robbie Gemmell]

I haven't tried this, and what i'm about to say may not fully explain
all the behaviour you describe, though I expected its related to the
overall situation.

The 'durable' option will then be causing it to create a durable topic
subscriber, on your given destination. As there is no setting passing
a subscription name, it is presumably creating its own stable name in
some way. It will thus presumably be using the same subscription name
when operating for both commands, and this seems likely to be the key
point.

JMS only allows to have 1 durable subscription with a given
subscription name per ClientID. If you reuse the subscription name for
a for a different destination with the same ClientID then you
effectively create a new replacement subscription with the name at
that point. This is done server-side.

"If an unshared durable subscription already exists with the same name
and client identifier but a different topic, message selector or
noLocal value has been specified, and there is no consumer already
active (i.e. not closed) on the durable subscription then this is
equivalent to unsubscribing (deleting) the old one and creating a new
one."
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-

In short, you need to use a different Client ID (leverages the AMQP
container-id to pass it), or different subscription names (leverages
the AMQP link name to pass it) to avoid two distinct unshared durable
subscriptions from interfering with each other.

On Fri, 4 Jun 2021 at 12:22, La Fleur, Sebastiaan
 wrote:
>
> Good afternoon all!
>
> Artemis version: 2.17.0
>
> This week I ran into a behavior of Artemis that I did not expect nor fully 
> understand so I hope that with this e-mail someone is able to point me to the 
> relevant documentation.
>
> TL;DR:
> Say we have a durable queue configured connected as multicast to the address 
> (so it is a topic) and we have a sender who sends a durable message to the 
> queue every 1 second with a different body.
> Then we can connect a receiver and depending on if the multicast address 
> prefix is added, all pending and new messages are received or only new 
> messages are received.
>
> Details:
> Queue configuration in broker.xml:
> 
> 1
> 1000
> BLOCK
> true
> false
> false
> false
> 6
> 60480
> 
> MULTICAST
>  
>
> 
> 
> 
>  
>
> I have been able to reproduce this using the Artemis CLI client:
>
> To produce $ ./artemis producer --user someUser --password somePW --url 
> amqp://localhost:5672 --sleep 1000 --protocol amqp --destination 
> topic://foobar --verbose
>
> To consume ALL  $ ./artemis consumer --durable --protocol amqp --user 
> someUser --password somePW  --clientID artemisconsole --destination 
> topic://foobar --url amqp://localhost:5672 --verbose
>
> To consume NEW only $ ./artemis consumer --durable --protocol amqp --user 
> someUser --password somePW --clientID artemisconsole --destination 
> topic://multicast:foobar --url amqp://localhost:5672 --verbose
>
> The producer command runs in the background and is continuously sending 
> messages. Now if I run the ALL consume command, the queue is created and I 
> will receive messages from that point on. If I quit the command with 
> (CTRL+C), wait a couple of seconds and run the ALL command again, I will 
> receive all queued, pending messages and any new messages.
>
> Now if I run the NEW consume command, another queue is created and I will 
> receive messages from that point on. If I quit the command with (CTRL+C), 
> wait a couple of seconds and run the NEW command again, I will NOT received 
> the queued, pending messages and will ONLY receive the messages that are new 
> from that point on. All pending, queued messages are removed and the queue 
> gets a new ID according to queue attributes in the management web ui.
>
> The only difference between the 2 receiver commands is the addition of the 
> multicast: prefix in the Artemis/AMQP address.
>
> Now if I look in the web GUI, I do see that the queue attribute ID stays the 
> same whenever the ALL command (re)connects while the queue attribute ID 
> changes whenever the NEW command (re)connects. An example of where I found 
> this id: https://imgur.com/a/pmJPnkd
>
> I have discovered this behavior with a programmatic Python Proton client but 
> the steps written in this e-mail uses the artemis binary to make it easily 
> reproducible and show the behavior probably originates from the broker.
>
> Curious to hear if this is expected behavior! Could someone point me to the 
> relevant documentation?
>
>
> Thank you in advance!
>
> Sincere regards,
>
> Sebastiaan la Fleur
>
>
>
>
>
>
> 
>
> Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor 
> (gebruik door) de

Re: Understanding of Artemis multicastPrefix in AMQP address prevents the transfer of historical and pending messages of queue

[Robbie Gemmell]

l only the receiver to 
> reuse the existing durable subscription.
>
> Hopefully this leads to a better understanding of the issue I am 
> investigating. Curious if anyone has any other insights. Or could I have 
> discovered a bug? Thank you in advance!
>
>
> Regards,
>
> Sebastiaan la Fleur
>
>
>
> Minimal broker.xml:
> 
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:xi="http://www.w3.org/2001/XInclude";
>xsi:schemaLocation="urn:activemq 
> /schema/artemis-configuration.xsd">
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="urn:activemq:core ">
>
>   ARTEMIS
>
>   
>   name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpMinLargeMessageSize=102400;amqpDuplicateDetection=true;anycastPrefix=anycast:;multicastPrefix=multicast:;sslEnabled=false
>   
>
>   
>   
> 
> 
> 
> 
> 
> 
>     
> 
> 
> 
>  
>   
>
>
>   
>  
> 
> 1
> 1000
> BLOCK
> true
> true
> false
> true
> 6
> 60480
> MULTICAST
> 
> MULTICAST
>  
>   
>
>   
>
>  
> 
> 
>  
>   
>
> 
>
>
> -Original Message-
> From: Robbie Gemmell 
> Sent: dinsdag 8 juni 2021 16:49
> To: users@activemq.apache.org
> Subject: Re: Understanding of Artemis multicastPrefix in AMQP address 
> prevents the transfer of historical and pending messages of queue
>
> I haven't tried this, and what i'm about to say may not fully explain all the 
> behaviour you describe, though I expected its related to the overall 
> situation.
>
> The 'durable' option will then be causing it to create a durable topic 
> subscriber, on your given destination. As there is no setting passing a 
> subscription name, it is presumably creating its own stable name in some way. 
> It will thus presumably be using the same subscription name when operating 
> for both commands, and this seems likely to be the key point.
>
> JMS only allows to have 1 durable subscription with a given subscription name 
> per ClientID. If you reuse the subscription name for a for a different 
> destination with the same ClientID then you effectively create a new 
> replacement subscription with the name at that point. This is done 
> server-side.
>
> "If an unshared durable subscription already exists with the same name and 
> client identifier but a different topic, message selector or noLocal value 
> has been specified, and there is no consumer already active (i.e. not closed) 
> on the durable subscription then this is equivalent to unsubscribing 
> (deleting) the old one and creating a new one."
> https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-
>
> In short, you need to use a different Client ID (leverages the AMQP 
> container-id to pass it), or different subscription names (leverages the AMQP 
> link name to pass it) to avoid two distinct unshared durable subscriptions 
> from interfering with each other.
>
> On Fri, 4 Jun 2021 at 12:22, La Fleur, Sebastiaan 
>  wrote:
> >
> > Good afternoon all!
> >
> > Artemis version: 2.17.0
> >
> > This week I ran into a behavior of Artemis that I did not expect nor fully 
> > understand so I hope that with this e-mail someone is able to point me to 
> > the relevant documentation.
> >
> > TL;DR:
> > Say we have a durable queue configured connected as multicast to the 
> > address (so it is a topic) and we have a sender who sends a durable message 
> > to the queue every 1 second with a different body.
> > Then we can connect a receiver and depending on if the multicast address 
> > prefix is added, all pending and new messages are received or only new 
> > messages are received.
> >
> > Details:
> > Queue configuration in broker.xml:
> > 
> > 1
> > 1000
> > BLOCK
> > true
> > false
> > false
> > false
> > 6
>

Re: need details of parallel processing

[Robbie Gemmell]

It would seem you aren't failing to subscribe, but rather failing to
create a Connection upon which attempt could even be made to
subscribe. The exception looks to give the reason fairly clearly, it
seems you are trying to create a connection using a ClientID that is
already in use for another connection. You can only create a single
Connection with a given ClientID.

Either define additional connection factories with different ClientID
values configured and use them to create 1 connection each, or stop
configuring an explicit ClientID for the factory and set it on each
connection immediately after creation, or dont do either and accept
the client-generated value (not an option if you want to use durable
subscriptions, which require a ClientID be set).


On Fri, 2 Jul 2021 at 13:23, NawazAli Shaik
 wrote:
>
> Hi Tim,
>
> Yes you are correct we are failing to subscribe the messages from topic. 
> Below is the error which we are getting:
>
> com.wm.app.b2b.server.jms.JMSSubsystemException: [ISS.0134.9064] Error 
> creating connection: javax.jms.InvalidClientIDException: Broker: 
> app-intg-platform-sit-retail-corp-broker-3 - Client: testingcluster already 
> connected from tcp://
>
>
> Thanks & Regards,
> Nawaz Ali Shaik
> Integration Support | Digital & Technology Service Operations
> Sainsbury's Supermarkets Ltd | Walsgrave,Coventry
> nawazali.sh...@sainsburys.co.uk | Mobile: +44-7405734657
>
>  www.sainsburys.co.uk
>
>
> -Original Message-
> From: Tim Bain 
> Sent: 02 July 2021 13:19
> To: ActiveMQ Users 
> Cc: michael.andre.pearce 
> Subject: Re: need details of parallel processing
>
> 
>
> CAUTION: This message was sent to you from outside of the organisation. Do 
> not click links or open attachments unless you are expecting the email and 
> know the content is safe.
>
> 
>
> Nawaz,
>
> Are your threads failing to subscribe to the destination, or failing to 
> receive messages as expected after subscribing? You said that enabling the 
> trigger in the client is failing, so am I right to understand that this is a 
> failure to subscribe to the topic, not a failure to process messages as 
> expected once successfully subscribed?
>
> Are there any relevant error messages?
>
> Thanks,
> Tim
>
> On Fri, Jul 2, 2021, 5:54 AM NawazAli Shaik 
> wrote:
>
> > Hi Tim,
> >
> > The active mq version is recently updated to Apache ActiveMQ 5.16.2.
> > We are trying to subscribe the messages from active mqueue topic parllely .
> >
> > In webmethods we have triggers to subscribe the messages from
> > topics/queues, we are not able to enable the triggers itself from the
> > client side.
> >
> > Thanks & Regards,
> > Nawaz Ali Shaik
> > Integration Support | Digital & Technology Service Operations
> > Sainsbury's Supermarkets Ltd | Walsgrave,Coventry
> > nawazali.sh...@sainsburys.co.uk | Mobile: +44-7405734657
> >
> >  www.sainsburys.co.uk
> >
> >
> > -Original Message-
> > From: Tim Bain 
> > Sent: 02 July 2021 12:42
> > To: ActiveMQ Users 
> > Cc: michael.andre.pearce 
> > Subject: Re: need details of parallel processing
> >
> > 
> >
> > CAUTION: This message was sent to you from outside of the
> > organisation. Do not click links or open attachments unless you are
> > expecting the email and know the content is safe.
> >
> > 
> >
> > Can you please tell us more about what you're doing and in what way
> > it's not working? Is this a queue or a topic? Are your threads failing
> > to subscribe to the destination, or failing to receive messages as
> > expected after subscribing? What behavior are you expecting, and what
> > behavior are you observing instead? Are there any relevant error messages?
> >
> > Thanks,
> > Tim
> >
> > On Thu, Jul 1, 2021, 3:32 PM NawazAli Shaik <
> > nawazali.sh...@sainsburys.co.uk>
> > wrote:
> >
> > > Hi Michael,
> > >
> > > Thanks for responding. We are using Amazon mqueue which is a managed
> > > broker service for active mqueue.
> > >
> > > The version of active mqueue is 5.15.*.
> > >
> > > Regards,
> > >
> > > Nawaz Ali Shaik
> > > 
> > > From: michael.andre.pearce 
> > > Sent: 01 July 2021 20:18
> > > To: users@activemq.apache.org 
> > > Subject: RE: need details of parallel processing
> > >
> > > 
> > >
> > > CAUTION: This message was sent to you from outside of the
> > > organisation. Do not click links or open attachments unless you are
> > > expecting the email and know the content is safe.
> > >
> > > 
> > >
> > > Are you testing ActiveMQ Artemis? If so which version are you having
> > > issue with?Sent from my Galaxy
> > >  Original message From: NawazAli Shaik <
> > > nawazali.sh...@sainsburys.co.uk> Date: 01/07/2021  18:39
> > > (GMT+00:00)
> > To:
> > > users@activemq.apache.org Subject: need details of parallel
> > > processi

Re: [PROPOSAL] Remove nabble links from website

[Robbie Gemmell]

There is also https://lists.apache.org/list.html?users@activemq.apache.org

On Fri, 13 Aug 2021 at 17:12, Dyck, Trevor  wrote:
>
> Sounds great, thank-you.
>
> -Original Message-
> From: Justin Bertram 
> Sent: Friday, August 13, 2021 9:09 AM
> To: users@activemq.apache.org
> Subject: RE: [EXTERNAL] [PROPOSAL] Remove nabble links from website
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
>
>
>
> There are links to 2 archive sites next to where the old Nabble link was - 
> Apache and Markmail.
>
> You can search the Apache archive by prefixing a Google or DuckDuckGo search 
> with "site:", e.g. "site:
> http://mail-archives.apache.org/mod_mbox/activemq-users/ clustering"
>
> The Markmail archive has a built-in search feature.
>
>
> Justin
>
> On Fri, Aug 13, 2021 at 10:47 AM Dyck, Trevor 
> wrote:
>
> > I found Nabble useful for searching past discussions - is there
> > another way to search those easily besides Nabble?
> >
> > Thanks,
> > Trevor
> >
> > > On Aug 13, 2021, at 7:49 AM, Jean-Baptiste Onofré 
> > wrote:
> > >
> > > CAUTION: This email originated from outside of the organization. Do
> > > not
> > click links or open attachments unless you can confirm the sender and
> > know the content is safe.
> > >
> > >
> > >
> > > Hi guys,
> > >
> > > I created pull request
> > > https://github.com/apache/activemq-website/pull/56 on website to
> > > remove the nabble link from the contact page.
> > >
> > > Since nabble downgraded their servers capacity, a bunch of forums
> > > linked to mailing list are not available anymore. It's the case for
> > > several Apache projects, including Apache ActiveMQ.
> > >
> > > Users should use mailing list and eventually slack (but remember, if
> > > it doesn't happen on the mailing list, it never happens, so
> > > discussions on slack should moved to mailing list at some point).
> > >
> > > If there's no objection, I will merge PR #56.
> > >
> > > Thanks,
> > > Regards
> > > JB
> >

Re: [PROPOSAL] Remove nabble links from website

[Robbie Gemmell]

I updated the site earlier

On Mon, 16 Aug 2021 at 14:38, Justin Bertram  wrote:
>
> Bruce, I sent the email you requested. The subject is "[HEADS-UP]
> ActiveMQ/Nabble integration is defunct."
>
> Robbie, thanks for that link. I didn't know that existed. That seems like a
> great option! I'll reply to my thread with this and update the website as
> well.
>
>
> Justin
>
> On Mon, Aug 16, 2021 at 5:11 AM Robbie Gemmell 
> wrote:
>
> > There is also https://lists.apache.org/list.html?users@activemq.apache.org
> >
> > On Fri, 13 Aug 2021 at 17:12, Dyck, Trevor 
> > wrote:
> > >
> > > Sounds great, thank-you.
> > >
> > > -Original Message-
> > > From: Justin Bertram 
> > > Sent: Friday, August 13, 2021 9:09 AM
> > > To: users@activemq.apache.org
> > > Subject: RE: [EXTERNAL] [PROPOSAL] Remove nabble links from website
> > >
> > > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the content is safe.
> > >
> > >
> > >
> > > There are links to 2 archive sites next to where the old Nabble link was
> > - Apache and Markmail.
> > >
> > > You can search the Apache archive by prefixing a Google or DuckDuckGo
> > search with "site:", e.g. "site:
> > > http://mail-archives.apache.org/mod_mbox/activemq-users/ clustering"
> > >
> > > The Markmail archive has a built-in search feature.
> > >
> > >
> > > Justin
> > >
> > > On Fri, Aug 13, 2021 at 10:47 AM Dyck, Trevor
> > 
> > > wrote:
> > >
> > > > I found Nabble useful for searching past discussions - is there
> > > > another way to search those easily besides Nabble?
> > > >
> > > > Thanks,
> > > > Trevor
> > > >
> > > > > On Aug 13, 2021, at 7:49 AM, Jean-Baptiste Onofré 
> > > > wrote:
> > > > >
> > > > > CAUTION: This email originated from outside of the organization. Do
> > > > > not
> > > > click links or open attachments unless you can confirm the sender and
> > > > know the content is safe.
> > > > >
> > > > >
> > > > >
> > > > > Hi guys,
> > > > >
> > > > > I created pull request
> > > > > https://github.com/apache/activemq-website/pull/56 on website to
> > > > > remove the nabble link from the contact page.
> > > > >
> > > > > Since nabble downgraded their servers capacity, a bunch of forums
> > > > > linked to mailing list are not available anymore. It's the case for
> > > > > several Apache projects, including Apache ActiveMQ.
> > > > >
> > > > > Users should use mailing list and eventually slack (but remember, if
> > > > > it doesn't happen on the mailing list, it never happens, so
> > > > > discussions on slack should moved to mailing list at some point).
> > > > >
> > > > > If there's no objection, I will merge PR #56.
> > > > >
> > > > > Thanks,
> > > > > Regards
> > > > > JB
> > > >
> >
> >

Re: SSL error as of artemis 2.18.0

[Robbie Gemmell]

Technically I updated it in both, I created ARTEMIS-3421 and made the
change against it so its in the next release notes, and also mentioned
ARTEMIS-3367 so it can also be seen by anyone happening across the
original change via there.

I tweaked the default doc and clarified what the setting does a bit. I
think perhaps Justin was thinking something more explicit about what a
failure on mismatch means and what can be done.

Robbie

On Mon, 23 Aug 2021 at 08:01, Dondorp, Erwin  wrote:
>
> Justin,
>
> You just saved me a lot of time, thx!
>
> FYI, I see that Robbie updated the documentation on 18-aug, but in 
> ARTEMIS-3421.
>
> e.
>
> -Oorspronkelijk bericht-
> Van: Justin Bertram 
> Verzonden: maandag 23 augustus 2021 03:51
> Aan: users@activemq.apache.org
> Onderwerp: Re: SSL error as of artemis 2.18.0
>
>
> EXTERNAL SENDER:   Do not click any links or open any attachments unless you 
> trust the sender and know the content is safe.
> EXPÉDITEUR EXTERNE:Ne cliquez sur aucun lien et n’ouvrez aucune pièce 
> jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez 
> l'assurance que le contenu provient d'une source sûre.
>
> The change in question is from ARTEMIS-3367 [1]. Since the hostname defined 
> in the SSL cert on your broker can't be verified then you should either get a 
> new cert for your broker for which the hostname *can* be verified or set 
> verifyHost=false on the connector for the cluster-connection.
>
> I'll make this more clear in the relevant documentation [1].
>
>
> Justin
>
> [1] 
> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/ARTEMIS-3367__;!!AaIhyw!9jkvRaZw1t4ba7OJzuo06w1EHZjmVsuMXrIaZq_LM9dWoqg252BBlmBkKP1fenty$
> [2]
> https://urldefense.com/v3/__https://activemq.apache.org/components/artemis/documentation/latest/versions.html__;!!AaIhyw!9jkvRaZw1t4ba7OJzuo06w1EHZjmVsuMXrIaZq_LM9dWoqg252BBlmBkKCNafbTO$
>
> On Sun, Aug 22, 2021 at 8:09 PM Dondorp, Erwin 
> wrote:
>
> > Hello!
> >
> > Since Artemis 2.18.0, the broker-broker connections (for clustering)
> > refuse to connect due to "Caused by:
> > java.security.cert.CertificateException: No name matching [hostname]
> > found". I did not try any client connections yet, so these might just
> > have the same problem.
> > My setup is the simplest possible SSL with self-signed certificates
> > since it is a development system.
> > While looking through the release notes (and zooming in on some of the
> > Jira issues), I did not quickly spot a change that would cause this.
> > I did not have this problem when using the snapshot versions of
> > 2.18.0, but the last version I actually checked was
> > apache-artemis-2.18.0-20210730.150450-205-bin.tar.gz.
> > So the question is: what was actually changed? (or is broken? can't
> > believe that).
> >
> > thx,
> > Erwin
> >

Re: SSL error as of artemis 2.18.0

[Robbie Gemmell]

The first bit is slightly more nuanced meaning there is another
possibility (which is what actually occurred in ARTEMIS-3421), so I
would state it a little differently:

Change the hostname value that is being connected to in the broker
config, so it can match against the existing certificate offered, or
change the certificate (e.g adding appropriate subject alternative
names) so that it can match whatever hostname value is being connected
to. If not those then you would need to consider verifyHost=false
() to permit the mismatch.

On Mon, 23 Aug 2021 at 02:51, Justin Bertram  wrote:
>
> The change in question is from ARTEMIS-3367 [1]. Since the hostname defined
> in the SSL cert on your broker can't be verified then you should either get
> a new cert for your broker for which the hostname *can* be verified or set
> verifyHost=false on the connector for the cluster-connection.
>
> I'll make this more clear in the relevant documentation [1].
>
>
> Justin
>
> [1] https://issues.apache.org/jira/browse/ARTEMIS-3367
> [2]
> https://activemq.apache.org/components/artemis/documentation/latest/versions.html
>
> On Sun, Aug 22, 2021 at 8:09 PM Dondorp, Erwin 
> wrote:
>
> > Hello!
> >
> > Since Artemis 2.18.0, the broker-broker connections (for clustering)
> > refuse to connect due to "Caused by:
> > java.security.cert.CertificateException: No name matching [hostname]
> > found". I did not try any client connections yet, so these might just have
> > the same problem.
> > My setup is the simplest possible SSL with self-signed certificates since
> > it is a development system.
> > While looking through the release notes (and zooming in on some of the
> > Jira issues), I did not quickly spot a change that would cause this.
> > I did not have this problem when using the snapshot versions of 2.18.0,
> > but the last version I actually checked was
> > apache-artemis-2.18.0-20210730.150450-205-bin.tar.gz.
> > So the question is: what was actually changed? (or is broken? can't
> > believe that).
> >
> > thx,
> > Erwin
> >

Re: SSL error as of artemis 2.18.0

[Robbie Gemmell]

Well, I didnt create it so much as update the description to repurpose
it rather than simply close it hehe.

On Mon, 23 Aug 2021 at 09:34, Robbie Gemmell  wrote:
>
> Technically I updated it in both, I created ARTEMIS-3421 and made the
> change against it so its in the next release notes, and also mentioned
> ARTEMIS-3367 so it can also be seen by anyone happening across the
> original change via there.
>
> I tweaked the default doc and clarified what the setting does a bit. I
> think perhaps Justin was thinking something more explicit about what a
> failure on mismatch means and what can be done.
>
> Robbie
>
> On Mon, 23 Aug 2021 at 08:01, Dondorp, Erwin  wrote:
> >
> > Justin,
> >
> > You just saved me a lot of time, thx!
> >
> > FYI, I see that Robbie updated the documentation on 18-aug, but in 
> > ARTEMIS-3421.
> >
> > e.
> >
> > -Oorspronkelijk bericht-
> > Van: Justin Bertram 
> > Verzonden: maandag 23 augustus 2021 03:51
> > Aan: users@activemq.apache.org
> > Onderwerp: Re: SSL error as of artemis 2.18.0
> >
> >
> > EXTERNAL SENDER:   Do not click any links or open any attachments unless 
> > you trust the sender and know the content is safe.
> > EXPÉDITEUR EXTERNE:Ne cliquez sur aucun lien et n’ouvrez aucune pièce 
> > jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous 
> > ayez l'assurance que le contenu provient d'une source sûre.
> >
> > The change in question is from ARTEMIS-3367 [1]. Since the hostname defined 
> > in the SSL cert on your broker can't be verified then you should either get 
> > a new cert for your broker for which the hostname *can* be verified or set 
> > verifyHost=false on the connector for the cluster-connection.
> >
> > I'll make this more clear in the relevant documentation [1].
> >
> >
> > Justin
> >
> > [1] 
> > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/ARTEMIS-3367__;!!AaIhyw!9jkvRaZw1t4ba7OJzuo06w1EHZjmVsuMXrIaZq_LM9dWoqg252BBlmBkKP1fenty$
> > [2]
> > https://urldefense.com/v3/__https://activemq.apache.org/components/artemis/documentation/latest/versions.html__;!!AaIhyw!9jkvRaZw1t4ba7OJzuo06w1EHZjmVsuMXrIaZq_LM9dWoqg252BBlmBkKCNafbTO$
> >
> > On Sun, Aug 22, 2021 at 8:09 PM Dondorp, Erwin 
> > wrote:
> >
> > > Hello!
> > >
> > > Since Artemis 2.18.0, the broker-broker connections (for clustering)
> > > refuse to connect due to "Caused by:
> > > java.security.cert.CertificateException: No name matching [hostname]
> > > found". I did not try any client connections yet, so these might just
> > > have the same problem.
> > > My setup is the simplest possible SSL with self-signed certificates
> > > since it is a development system.
> > > While looking through the release notes (and zooming in on some of the
> > > Jira issues), I did not quickly spot a change that would cause this.
> > > I did not have this problem when using the snapshot versions of
> > > 2.18.0, but the last version I actually checked was
> > > apache-artemis-2.18.0-20210730.150450-205-bin.tar.gz.
> > > So the question is: what was actually changed? (or is broken? can't
> > > believe that).
> > >
> > > thx,
> > > Erwin
> > >

Re: TLS 1.3

[Robbie Gemmell]

To add to the below, Java 11+ has TLS 1.3 enabled by default, e.g for
the generic "TLS" protocol name, so unless something specifically
restricts the enabledProtocols then it will be enabled.

I believe more recent Java 8 JVMs have it enabled by default on the
server side, but not the client side, requiring them to explicitly
enable it (using mechanisms such as below) for them to actually use it
in order to not affect compatibility.

(I assume the version was meant to be 5.16.2, there doesn't look to be
a 5.6.12, though it would be ancient if there were)

On Fri, 15 Oct 2021 at 01:46, Justin Bertram  wrote:
>
> Whether or not TLS 1.3 works for you really depends on the JVM you're
> using. The "enabledProtocols" settings are passed through to the underlying
> instance of javax.net.ssl.SSLEngine provided by the JVM [1].
>
>
> Justin
>
> [1]
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLEngine.html#setEnabledProtocols(java.lang.String%5B%5D)
>
> On Thu, Oct 14, 2021 at 4:24 PM martin naskovski 
> wrote:
>
> > Hello - can I configure ActiveMQ 5.6.12 with TLS 1.3? I've a requirement to
> > support TLS 1.3 in addition to TLS 1.2. The documentation says to add the
> > protocol like so:
> >
> > transport.enabledProtocols=TLSv1.2,TLSv1.3
> > socket.enabledProtocols=TLSv1.2,TLSv1.3
> >
> > but I am paranoid if this is a tested/supported configuration. Has anyone
> > else gotten TLS 1.3 working with ActiveMQ?
> >
> > Thank you,
> > Martin
> >

Re: [EXTERNAL] Re: ActiveMQ 5.x end of life info

[Robbie Gemmell]

You would need to upgrade to a 'current' minor version, i.e something
from the website download page which is still seeing releases,
typically the latest stream and sometimes an older one.

On Fri, 15 Oct 2021 at 08:28, Giuseppe Sarno
 wrote:
>
> Hello,
> Thanks both. Should have been bit more specific. What about individual minor 
> versions ? Are those maintained for security patches for example ? let's say 
> I am on 5.13.4 what do I need to do to fix CVE ? will I need to move to a 
> different minor version ? 16 in this case ? or will there be release a new 
> 5.13.5 ?
>
> Thanks,
> Giuseppe.
>
> -Original Message-
> From: JB Onofré 
> Sent: 14 October 2021 20:55
> To: users@activemq.apache.org
> Subject: [EXTERNAL] Re: ActiveMQ 5.x end of life info
>
> CAUTION: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
> In addition to Lucas’ info, ActiveMQ 5.x (if it’s the question) is still 
> active and not EOL.
>
> Regards
> JB
>
> > Le 14 oct. 2021 à 21:25, Giuseppe Sarno  a 
> > écrit :
> >
> > Hello,
> > Is it possible to have information on EOL for the different versions of 
> > ActiveMQ from 5.x onwards ?
> >
> > Best Regards.
> > This email and any files transmitted with it are confidential, proprietary 
> > and intended solely for the individual or entity to whom they are 
> > addressed. If you have received this email in error please delete it 
> > immediately.
>
> This email and any files transmitted with it are confidential, proprietary 
> and intended solely for the individual or entity to whom they are addressed. 
> If you have received this email in error please delete it immediately.

Re: Confusion around reusing session, producer, consumer, ...

[Robbie Gemmell]

Setting a MessageListener on a consumer dedicates the Session to its
asynchronous message delivery thread of control [while the connection
is started]. So sending with one thread and also having listener(s)
being delivered consumed messages on the same session is still
multi-threading the session.

Using a synchronous receive(..) calls to consume replies, instead of a
MessageListener, might be more appropriate than setting a listener if
you want/need to use a single session for send+recieve. You would then
only have one application thread using the session. Alternatively,
MessageListener callbacks can also send.

The comments are suggesting that you can use the same queue for
multiple responses [concurrently] by mapping the arriving response to
a particular request through use of a JMSCorrelationID value set on
the message, which you included on the request and that the responder
then sets on its reply back so that you can correlate them. A reply-to
queue does not need to be a TemporaryQueue either way, you can also
use fixed queues, and often you might need to depending on your
reliability needs for the responses etc.


On Wed, 17 Nov 2021 at 18:25, Yann Massard  wrote:
>
> Hi,
>
> working with Artemis, I am trying to understand how to reuse a session
> and corresponding producer and consumer in a request-reply scenario. I
> have started with the RequestReplyExample and tried to make it work with
> multiple requests/responses. After all, the example's comments say:
>
> "Of course, in a real world example you would re-use the session,
> producer, consumer and temporary queue and not create a new one for each
> message!"
>
> Since I know that sessions should not be used by multiple threads, I am
> making sure, all messages are sent through the same thread.
>
> (My code is at the very bottom of this message.)
>
> However, I still get exceptions:
>
> Nov 17, 2021 6:42:58 PM
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl startCall
> WARN: AMQ212051: Invalid concurrent session usage. Sessions are not
> supposed to be used by more than one thread concurrently.
> java.lang.Exception: trace
>  at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.startCall(ClientSessionImpl.java:1587)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.acknowledge(ClientSessionImpl.java:1209)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.doAck(ClientConsumerImpl.java:1117)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.acknowledge(ClientConsumerImpl.java:788)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientMessageImpl.acknowledge(ClientMessageImpl.java:136)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientMessageImpl.acknowledge(ClientMessageImpl.java:38)
>  at
> org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:136)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1013)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1133)
>  at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
>  at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>
>
> As soon as I remove the client's MessageListener, the exceptions are
> gone. So I assume that sending the ACK (see stack trace) is done by
> another thread and that might be the problem. However, I don't know how
> to change this.
>
> Can anybody give me a hint how to procede?
>
> Btw. the comment also says:
>
> "Or better still use the correlation id, and just store the requests in
> a map, then you don't need a temporary queue at all"
>
> I am very interested but have no idea how this is supposed to work.
> Which queue should the responses be sent through?
>
> Any help is greatly appreciated!
>
> Thank you!
>
> Yann
>
>
> package org.apache.activemq.artemis.jms.example;
>
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;
>
> import javax.jms.*;
> import java.util.concurrent.Executor;
> import java.util.concurrent.Executors;
>
> public class RequestReplyExample {
>
> public static void main(final String[] args)throws Exception {
>new Server().start();
>Client client =new Client();
>for (int i =0; i <100; i++) {
>   client.sendJob("message-" + i);
>}
> }
> }
>
> class Client {
>
> private fi

Re: Upcoming releases

[Robbie Gemmell]

Updating the site isnt actually hard at all, but its surprising how
often people still manage not to get round to it for one reason or
another. I recall on numerous occasions of asking about site updates
for otherwise complete releases, sometimes weeks later. The last time
adding a 'next release date' on the site was discussed, I recall
observing that the dates on the cited exemplar project site were
actually all stale at the time and in the past by some amount up to a
year. To me, dates or those with no actual substance behind them are
actually often just misleading and worse than just not suggesting
dates. Many projects dont list dates, perhaps even 'most'.

I dont think a vague quarterly promise is really going to be any
better based on prior patterns. Many releases have been way over or
way under that frequency, and since it seems in general no specific
schedule is usually being worked to it I would avoid generally
suggesting it is. I would just try doing more frequent, smaller,
releases at points it is appropropriate to the work actually going on
in the repo.

Robbie

On Tue, 1 Feb 2022 at 18:12, Jean-Baptiste Onofre  wrote:
>
> Hi Justin,
>
> I think it’s not a huge effort compare to what we already do at each release 
> (updating the website).
>
> For instance, for Karaf, it’s pretty quick to update website and release 
> schedule at each release cycle.
>
> I already proposed regular release cycle in the past (as best effort).
>
> I would agree with both: regular release cycle (quarterly) + some details (at 
> least for “major” releases) on website.
>
> Regards
> JB
>
> > Le 1 févr. 2022 à 18:32, Justin Bertram  a écrit :
> >
> > Generally speaking, I'm against anything that will require more maintenance
> > of the website. History indicates that the community is somewhat weak in
> > this area.
> >
> > Correct me if I'm wrong, but from what I can tell we've never consistently
> > scheduled releases. Also, given the Apache Way with the release voting
> > process we can only be precise about when a release will go up for a vote.
> > There's no way to actually guarantee a release date. Why not have
> > consistent, time-boxed (e.g. quarterly) releases? That would solve a
> > handful of problems:
> >
> > - users could depend on a general cadence for releases
> > - the website could simply outline the release cadence which would
> > alleviate the need for maintenance
> > - it would reduce the communication necessary to coordinate a release; a
> > release manager could simply step up and perform the release when the time
> > comes
> >
> > Obviously we can still have "ad hoc" releases as necessary (e.g. due to a
> > security issue).
> >
> > Thoughts?
> >
> >
> > Justin
> >
> > On Tue, Feb 1, 2022 at 6:47 AM Tim Bain  wrote:
> >
> >> Would it be worth the effort to create and then maintain a page that lists
> >> the planned timeline of upcoming releases for both 5.x and Artemis? There
> >> have been a lot of questions about upcoming plans in the wake of the Log4J
> >> CVE, but even during normal times we get occasional questions here about
> >> upcoming plans, and that's just the users who bother to sign up for the
> >> mailing list so there could well be more who look for that info but don't
> >> post to ask.
> >>
> >> The downside is that once we create a page for that content we'll have to
> >> be diligent about updating it (including publishing updates when something
> >> slides back a bit), otherwise what's the point. I'm not sure if the folks
> >> who would have to do the ongoing work on this think it's worth the effort,
> >> but I wanted to throw it out for consideration.
> >>
> >> Tim
> >>
>