Re: [VOTE] Archive unused or out-of-date repos

2024-04-23 Thread Timothy Bish 

On 4/23/24 13:57, Justin Bertram wrote:

Following up from the previous discussion thread on this subject, I'd like
to propose a vote for archiving the following repos:

  - activemq-stomp - https://github.com/apache/activemq-stomp
  - activemq-activeio - https://github.com/apache/activemq-activeio
  - activemq-web - https://github.com/apache/activemq-web
  - activemq-nms-ems - https://github.com/apache/activemq-nms-ems
  - activemq-nms-xms - https://github.com/apache/activemq-nms-xms
  - activemq-nms-zmq - https://github.com/apache/activemq-nms-zmq
  - activemq-nms-msmq - https://github.com/apache/activemq-nms-msmq

Here's my +1.


Justin


+1

--
Tim Bish

Re: [VOTE] Apache ActiveMQ "Classic" 6.1.2 release

2024-04-11 Thread Timothy Bish 

On 4/11/24 16:08, Jean-Baptiste Onofré wrote:

Hi folks,

I submit Apache ActiveMQ "Classic" 6.1.2 release to your vote.

This release includes 8 fixes, especially:
- secure Jolokia and REST API by default
- fix on runtimeConfigurationPlugin JMX MBean reload operation
- fix when consuming empty destination via REST API
- fix client/server SSL socket configuration via URI

You can take a look on Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12354480

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1395/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/6.1.2/

Git tag: activemq-6.1.2

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source headers with 'mvn apache-rat:check'
* Ran binary broker install and checked that web console functions
* Built from source and ran a portion of the test suite.
* Ran a couple examples from a Qpid AMQP client


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.33.0

2024-03-20 Thread Timothy Bish 

On 3/19/24 19:12, Justin Bertram wrote:

I would like to propose an Apache ActiveMQ Artemis 2.33.0 release.

Here are some noteworthy updates in 2.33.0:

  - Support for JSON formatted typed properties on CLI producer command
  - New CLI command pwd for showing directories related to the current
instance
  - Maven Bill of Materials (BOM) artemis-bom to simplify integration
  - "FirstMessage" API for scheduled messages
  - New "view" and "edit" permissions for management operations configurable
via security-settings in broker.xml
  - New sslAutoReload parameter for the embedded web server configured in
`bootstrap.xml` to detect and automatically reload when SSL stores change
on disk
  - Performance improvements on mirroring and paging
  - Logging metrics to mitigate the risk of missing WARN or ERROR messages
in the log.
  - Much improved documentation on network isolation (aka split brain)
  - Pluggable lock manager (aka pluggable quorum voting) out of
"experimental" status and ready for general use

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12354184

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.33.0

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.33.0/

The Maven staging repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1391/

If you would like to validate the release:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases

It is tagged in the git repo as 2.33.0

[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1


Justin


+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source for license headers with 'mvn apache-rat:check'
* Ran the broker from the binary archive and exercised the web console
* Ran some the qpid-proton-dotnet client examples against the running 
broker

* Ran some the qpid-protonj2 client examples against the running broker
* Ran all the AMQP tests using: mvn clean install -DskipTests && cd 
tests/integration-tests/ && mvn test -Ptests 
-Dtest=org.apache.activemq.artemis.tests.integration.amqp.**



--
Tim Bish

Re: Upgrading the Artemis Console

2024-03-19 Thread Timothy Bish 

On 3/19/24 11:01, Justin Bertram wrote:

Done - https://github.com/apache/activemq-activemq-artemis-console-plugin

Looks like you included 'activemq' in the name when creating the repo so 
now you have two activemq's in the new repo name, likely should get that 
fixed.




Justin

On Tue, Mar 19, 2024 at 9:55 AM Andy Taylor  wrote:


Correct

On Tue, 19 Mar 2024, 14:29 Justin Bertram,  wrote:


Just to confirm...The repo name should be
"activemq-artemis-console-plugin", right?


Justin

On Tue, Mar 19, 2024 at 9:22 AM Andy Taylor 
wrote:


turns out I don't have permissions to create a repo, could someone from

the

PMC do this for me?

On Tue, 19 Mar 2024 at 09:27, Andy Taylor 

wrote:

I will go ahead and request the new repo today

On Mon, 18 Mar 2024 at 18:39, Timothy Bish 

wrote:

On 3/18/24 13:33, Andy Taylor wrote:

so I am open to names, how about artemis-console-plugin v1.0.0

+1



On Mon, 18 Mar 2024 at 17:24, Clebert Suconic <

clebert.suco...@gmail.com>

wrote:


+1 on activemq-artemis-console-plugin


As Robbie said, you will need different versions for it. I feel

like

it would be easier to use a different name... but I don't mind

what

you have to do. Whatever makes it easier to be implemented.


On Mon, Mar 18, 2024 at 1:10 PM Robbie Gemmell <

robbie.gemm...@gmail.com>

wrote:

On the module name, if it stays the same then consideration

would

also

need to be given to the version. It would need to be higher than
before to keep using the same name, but using a broker version

isnt

necessarily that obvious if we dont expect to release it on the

same

schedule as the broker.

On Mon, 18 Mar 2024 at 16:46, Andy Taylor <

andy.tayl...@gmail.com

wrote:

+1 for  avtivemq-artemis-console-plugin but I think we should

keep

the

artifact name as it is now for consistency, i.e. artemis-plugin

On Mon, 18 Mar 2024 at 16:29, Robbie Gemmell <

robbie.gemm...@gmail.com

wrote:


We should discuss the name then someone can create it via
https://selfserve.apache.org

It would be something of the form activemq-artemis- for
consistency. Regarding , what is actually going in it, a

console

'plugin' ?

So perhaps activemq-artemis-console-plugin ?

On Mon, 18 Mar 2024 at 07:46, Andy Taylor <

andy.tayl...@gmail.com

wrote:

Lets go with a separate repo then, @clebert or anyone, can

you

create me

a

new repo or talk me thru how to do it. What shall we call

this

new

component/repo, considering we will still have an

artemis-console

module

in

the artemis repo?

Clebert, I will add this new fields in your PR to the new

console

as

well.

Andy

On Fri, 15 Mar 2024 at 19:03, Clebert Suconic <

clebert.suco...@gmail.com

wrote:


I think we have a consensus on a separate repo.


@Andy:  me an Anton, we wre adding a field for internal

queues

in the

admin

console. If you could make sure we keep that on the new one

please ?

Or

let us know how to adjust it?


https://github.com/apache/activemq-artemis/pull/4856


On Thu, Mar 14, 2024 at 10:29 AM Justin Bertram <

jbert...@apache.org>

wrote:


+1 for a separate repo


Justin

On Thu, Mar 14, 2024 at 3:56 AM Andy Taylor <

andy.tayl...@gmail.com>

wrote:


Clebert, I think it will be weeks rather than days so I

would just

release

when you are ready.

Robbie, I think for now a separate repo is my preferred

solution,

the

console can actually be run outside of embedded artemis so

development

is

easy. Can someone create a new repo?

On Wed, 13 Mar 2024 at 17:45, Clebert Suconic <

clebert.suco...@gmail.com

wrote:


If it was a matter of 1 day to include it I would prefer

to wait

for

it.

Other than that then I’m releasing on Monday.


On Wed, Mar 13, 2024 at 1:40 PM Robbie Gemmell <

robbie.gemm...@gmail.com

wrote:


I'd say the answer to 'Wait for  to do a release?'

is

usually

no

unless its about a blocking bug/regression or there's

really

nothing

else important ready to go. This definitely isnt that

and also

isnt

ready yet while other stuff is, so seems a clear no to

me.

On Wed, 13 Mar 2024 at 16:58, Clebert Suconic <

clebert.suco...@gmail.com

wrote:

Should I wait for the 2.33 release ?


See my other thread about the heads up.


Or you think this may take a lot longer ?

On Wed, Mar 13, 2024 at 7:27 AM Andy Taylor <

andy.tayl...@gmail.com>

wrote:

The current Artemis console is based on HawtIO 1

which

itself

is

written

using Bootstrap. Bootstrap is old and no longer

maintained

so

HawtIO

(v3/4)

has moved to use React and Patternfly and is also

written

in

Typescript.

I have been working in the background over the last

several

months

to

upgrade the console to hawtIO 4, this work can be

found

here

<

https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng

.

This is still a WIP but is close to completion, I

basically

have

to

finish

off some branding, fix the console tests and

implement an

upgrade

feature.

A

Re: Upgrading the Artemis Console

2024-03-18 Thread Timothy Bish 

On 3/18/24 13:33, Andy Taylor wrote:

so I am open to names, how about artemis-console-plugin v1.0.0


+1



On Mon, 18 Mar 2024 at 17:24, Clebert Suconic 
wrote:


+1 on activemq-artemis-console-plugin


As Robbie said, you will need different versions for it. I feel like
it would be easier to use a different name... but I don't mind what
you have to do. Whatever makes it easier to be implemented.


On Mon, Mar 18, 2024 at 1:10 PM Robbie Gemmell 
wrote:

On the module name, if it stays the same then consideration would also
need to be given to the version. It would need to be higher than
before to keep using the same name, but using a broker version isnt
necessarily that obvious if we dont expect to release it on the same
schedule as the broker.

On Mon, 18 Mar 2024 at 16:46, Andy Taylor 

wrote:

+1 for  avtivemq-artemis-console-plugin but I think we should keep the
artifact name as it is now for consistency, i.e. artemis-plugin

On Mon, 18 Mar 2024 at 16:29, Robbie Gemmell 
We should discuss the name then someone can create it via
https://selfserve.apache.org

It would be something of the form activemq-artemis- for
consistency. Regarding , what is actually going in it, a console
'plugin' ?

So perhaps activemq-artemis-console-plugin ?

On Mon, 18 Mar 2024 at 07:46, Andy Taylor 

wrote:

Lets go with a separate repo then, @clebert or anyone, can you

create me

a

new repo or talk me thru how to do it. What shall we call this new
component/repo, considering we will still have an artemis-console

module

in

the artemis repo?

Clebert, I will add this new fields in your PR to the new console

as

well.

Andy

On Fri, 15 Mar 2024 at 19:03, Clebert Suconic <

clebert.suco...@gmail.com

wrote:


I think we have a consensus on a separate repo.


@Andy:  me an Anton, we wre adding a field for internal queues

in the

admin

console. If you could make sure we keep that on the new one

please ?

Or

let us know how to adjust it?


https://github.com/apache/activemq-artemis/pull/4856


On Thu, Mar 14, 2024 at 10:29 AM Justin Bertram <

jbert...@apache.org>

wrote:


+1 for a separate repo


Justin

On Thu, Mar 14, 2024 at 3:56 AM Andy Taylor <

andy.tayl...@gmail.com>

wrote:


Clebert, I think it will be weeks rather than days so I

would just

release

when you are ready.

Robbie, I think for now a separate repo is my preferred

solution,

the

console can actually be run outside of embedded artemis so

development

is

easy. Can someone create a new repo?

On Wed, 13 Mar 2024 at 17:45, Clebert Suconic <

clebert.suco...@gmail.com

wrote:


If it was a matter of 1 day to include it I would prefer

to wait

for

it.

Other than that then I’m releasing on Monday.


On Wed, Mar 13, 2024 at 1:40 PM Robbie Gemmell <

robbie.gemm...@gmail.com

wrote:


I'd say the answer to 'Wait for  to do a release?'

is

usually

no

unless its about a blocking bug/regression or there's

really

nothing

else important ready to go. This definitely isnt that

and also

isnt

ready yet while other stuff is, so seems a clear no to

me.

On Wed, 13 Mar 2024 at 16:58, Clebert Suconic <

clebert.suco...@gmail.com

wrote:

Should I wait for the 2.33 release ?


See my other thread about the heads up.


Or you think this may take a lot longer ?

On Wed, Mar 13, 2024 at 7:27 AM Andy Taylor <

andy.tayl...@gmail.com>

wrote:

The current Artemis console is based on HawtIO 1

which

itself

is

written

using Bootstrap. Bootstrap is old and no longer

maintained

so

HawtIO

(v3/4)

has moved to use React and Patternfly and is also

written

in

Typescript.

I have been working in the background over the last

several

months

to

upgrade the console to hawtIO 4, this work can be

found

here

<

https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng

.

This is still a WIP but is close to completion, I

basically

have

to

finish

off some branding, fix the console tests and

implement an

upgrade

feature.

A couple of things to note:


- I have separated out the JMX tree and its tabs

from

the

tabs

that

are

not related to the tree selection. I always found

this

a bit

strange so

now
there are 2 tabs Artemis and Artemis JMX, the

latter

uses

the

JMX

tree

as
before. It is possible however to do anything in

the

Artemis

tab

that

you
can do in the JMX tab, view attributes and

operations

for

instance.

There
is an issue currently where if there are

thousands of

address

or

queues

then performance becomes an issue. this is

because the

whole

JMX

tree is

loaded into memory and this can cause even the

broker to

fall

over.

My

plan
at some point is to allow disabling the JMX view

and to

lazy

load

in

MBeans
as and when needed, this is a task for further

down the

road

tho.

- The console is built using yarn and is

incredibly

slow to

build,

in

fact it takes longer than it takes to build the

rest of

Artemis.

It

may

be
better to have

Re: Upgrading the Artemis Console

2024-03-14 Thread Timothy Bish 

+1 for the separate repo approach

On 3/14/24 09:10, Domenico Francesco Bruscino wrote:

+1 separate repo

On Thu, 14 Mar 2024 at 14:07, Clebert Suconic 
wrote:


+1 separate repo

On Thu, Mar 14, 2024 at 7:12 AM Robbie Gemmell 
wrote:

That it can actually be run standalone would be another reason I'd
also choose to go with a separate repo.

Lets allow other folks time to chip in their opinions, if a separate
repo appears to be the consensus we can then look to create one.

On Thu, 14 Mar 2024 at 08:51, Andy Taylor 

wrote:

Clebert, I think it will be weeks rather than days so I would just

release

when you are ready.

Robbie, I think for now a separate repo is my preferred solution, the
console can actually be run outside of embedded artemis so development

is

easy. Can someone create a new repo?

On Wed, 13 Mar 2024 at 17:45, Clebert Suconic <

clebert.suco...@gmail.com>

wrote:


If it was a matter of 1 day to include it I would prefer to wait for

it.

Other than that then I’m releasing on Monday.


On Wed, Mar 13, 2024 at 1:40 PM Robbie Gemmell <

robbie.gemm...@gmail.com>

wrote:


I'd say the answer to 'Wait for  to do a release?' is usually

no

unless its about a blocking bug/regression or there's really

nothing

else important ready to go. This definitely isnt that and also isnt
ready yet while other stuff is, so seems a clear no to me.

On Wed, 13 Mar 2024 at 16:58, Clebert Suconic <

clebert.suco...@gmail.com

wrote:

Should I wait for the 2.33 release ?


See my other thread about the heads up.


Or you think this may take a lot longer ?

On Wed, Mar 13, 2024 at 7:27 AM Andy Taylor <

andy.tayl...@gmail.com>

wrote:

The current Artemis console is based on HawtIO 1 which itself

is

written

using Bootstrap. Bootstrap is old and no longer maintained so

HawtIO

(v3/4)

has moved to use React and Patternfly and is also written in

Typescript.

I have been working in the background over the last several

months to

upgrade the console to hawtIO 4, this work can be found here
<

https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng>.

This is still a WIP but is close to completion, I basically

have to

finish

off some branding, fix the console tests and implement an

upgrade

feature.

A couple of things to note:


- I have separated out the JMX tree and its tabs from the

tabs

that

are

not related to the tree selection. I always found this a bit

strange so

now
there are 2 tabs Artemis and Artemis JMX, the latter uses

the JMX

tree

as
before. It is possible however to do anything in the

Artemis tab

that

you
can do in the JMX tab, view attributes and operations for

instance.

There
is an issue currently where if there are thousands of

address or

queues

then performance becomes an issue. this is because the

whole JMX

tree is

loaded into memory and this can cause even the broker to

fall

over.

My

plan
at some point is to allow disabling the JMX view and to

lazy load

in

MBeans
as and when needed, this is a task for further down the

road tho.

- The console is built using yarn and is incredibly slow to

build,

in

fact it takes longer than it takes to build the rest of

Artemis.

It

may

be
better to have the new console in its own repository,

release it

independently and just consume it in Artemis. This means

some

extra

work

for a release but once the console becomes stable it

shouldn't be

too

much
work. I will however let the community decide what is the

best

approach.


There are still a few issues I know of, the Attributes tab

seems to

delay

loading and the broker topology diagram is incomplete but feel

free

to

suggest any improvements or buglets you come across on this

thread.

Hopefully I can tie up the loose ends soon and raise a PR in

the not

too

distant future.

Andy




--
Clebert Suconic



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.32.0

2024-01-25 Thread Timothy Bish 

On 1/24/24 16:29, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.32.0 release.


I would like to highlight the following for this release:


* Mirrored Core Messages can now be sent in their native format
without conversions
* Mirror has been extensively tested and improved in stability
* ActiveMQ Artemis has now adopted more inclusive language definitions.
* The examples are now part of its own repository:
https://github.com/apache/activemq-artemis-examples/


And bug fixes and other improvements as usually. for the full JIRA
report refer to:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353769



Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.32.0


Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.32.0

The Maven staging repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1384



If you would like to validate the release:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases




It is tagged in the git repo as 2.32.0


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source for license headers with 'mvn apache-rat:check'
* Ran the broker from the binary archive and exercised the web console
* Ran all the qpid-protonj2 client examples against the running broker
* Ran all the AMQP tests using: mvn clean install -DskipTests && cd 
tests/integration-tests/ && mvn test -Ptests 
-Dtest=org.apache.activemq.artemis.tests.integration.amqp.**


--
Tim Bish

Re: JMS API with client acknowledgement issue

2023-11-30 Thread Timothy Bish 

On 11/30/23 12:22, Justin Bertram wrote:

Tim, I think those are fair points. Ultimately I think the JavaDoc is
relatively ambiguous, although I tend to favor your interpretation.
To be honest I don't think it is, just read the first sentence and then 
ignore the fluff following as that is mainly trying to explain how / why 
this method is meant to be used.  It exists mainly because you can now 
consume the messages via receive body calls which will never give you a 
message to call acknowledge on if using client acknowledge mode.


What does the Qpid JMS client do in this case?
Qpid JMS has always handled this as a session level call and 
acknowledges as client ack would if message.acknowledge() were called.


BTW, I looked through the Jakarta Messaging TCK source code and I don't see
where this specific use-case is exercised.


That isn't terribly surprising given all the other cases the TCK doesn't 
check.





Justin

On Wed, Nov 29, 2023 at 3:58 PM Timothy Bish  wrote:


On 11/29/23 16:15, Justin Bertram wrote:

It's not clear to me that this is a defect. The JavaDoc for
JMSContext.acknowledge() [1] says (in part):


This method has identical behaviour to the acknowledge method on

Message.

A client may individually acknowledge each message as it is consumed, or

it

may choose to acknowledge messages as an application-defined group. In

both

cases it makes no difference which of these two methods is used.

If receive() returns a null Message Object you can't invoke acknowledge

on

it. Therefore, whether you use JMSContext.acknowledge() or
Message.acknowledge() the behavior will be identical - no message will be
acknowledged.

Also, it's worth noting that messages which are not acknowledged will not
be lost. In most cases they will be redelivered or in some cases may be
sent to a dead-letter address.

I believe you have skipped over the most important part of the API docs
for that method which is the first sentence which states:

"Acknowledges all messages consumed by the JMSContext's session."

That would imply it works on the session level regardless of any
successful (or not) calls to receive (or receiveBody which don't return
actual message objects) as it is meant to work against "all message
consumed by the JMSContext's session", not at the individual message
level which I'd guess is indeed why it was added to the "Simplified API"
as this would provide the entry point for  group acknowledge behavior
described in the text.

A previously read message from the 'receive' API is in fact a consumed
message within the session regardless of whether the most recent call
returned a message.



Justin

[1]


https://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html#acknowledge--

On Wed, Nov 29, 2023 at 4:08 AM Андрей  wrote:


Hi Team,

I am currently using "artemis-jakarta-client" 2.31.2 version

I've stumbled into an issue with client acknowledge mode when using JMS
API. Here's an example:


  try (var factory = new

ActiveMQConnectionFactory("
  try (var ctx = factory.createContext("",

"",

JMSContext.CLIENT_ACKNOWLEDGE)) {
  var destination = ctx.createQueue("");
  try (var consumer = ctx.createConsumer(destination)) {
  var message1 = consumer.receive(10); // suppose
this call returns real message
  var message2 = consumer.receive(10); // suppose
this call times out, so NULL is returned
  ctx.acknowledge(); // I'm expecting that message1

gets

acknowledged here, but it's not happening

  /*
  Do something here
   */

  }
  }
  }

The reason for ack not working is that the implementation of
"consumer.receive" method stores the latest returned value in JMSContext
for future usage in its "acknowledge" method.
This happens regardless if the value is null or not. So in case latest

call

returns null, all the previous messages get lost and never acked.

This seem like a defect. Am I right?

Thanks in advance


--
Tim Bish




--
Tim Bish

Re: JMS API with client acknowledgement issue

2023-11-29 Thread Timothy Bish 

On 11/29/23 16:15, Justin Bertram wrote:

It's not clear to me that this is a defect. The JavaDoc for
JMSContext.acknowledge() [1] says (in part):


This method has identical behaviour to the acknowledge method on Message.

A client may individually acknowledge each message as it is consumed, or it
may choose to acknowledge messages as an application-defined group. In both
cases it makes no difference which of these two methods is used.

If receive() returns a null Message Object you can't invoke acknowledge on
it. Therefore, whether you use JMSContext.acknowledge() or
Message.acknowledge() the behavior will be identical - no message will be
acknowledged.

Also, it's worth noting that messages which are not acknowledged will not
be lost. In most cases they will be redelivered or in some cases may be
sent to a dead-letter address.


I believe you have skipped over the most important part of the API docs 
for that method which is the first sentence which states:


"Acknowledges all messages consumed by the JMSContext's session."

That would imply it works on the session level regardless of any 
successful (or not) calls to receive (or receiveBody which don't return 
actual message objects) as it is meant to work against "all message 
consumed by the JMSContext's session", not at the individual message 
level which I'd guess is indeed why it was added to the "Simplified API" 
as this would provide the entry point for  group acknowledge behavior 
described in the text.


A previously read message from the 'receive' API is in fact a consumed 
message within the session regardless of whether the most recent call 
returned a message.





Justin

[1]
https://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html#acknowledge--

On Wed, Nov 29, 2023 at 4:08 AM Андрей  wrote:


Hi Team,

I am currently using "artemis-jakarta-client" 2.31.2 version

I've stumbled into an issue with client acknowledge mode when using JMS
API. Here's an example:


 try (var factory = new ActiveMQConnectionFactory("", "",
JMSContext.CLIENT_ACKNOWLEDGE)) {
 var destination = ctx.createQueue("");
 try (var consumer = ctx.createConsumer(destination)) {
 var message1 = consumer.receive(10); // suppose
this call returns real message
 var message2 = consumer.receive(10); // suppose
this call times out, so NULL is returned
 ctx.acknowledge(); // I'm expecting that message1 gets
acknowledged here, but it's not happening

 /*
 Do something here
  */

 }
 }
 }

The reason for ack not working is that the implementation of
"consumer.receive" method stores the latest returned value in JMSContext
for future usage in its "acknowledge" method.
This happens regardless if the value is null or not. So in case latest call
returns null, all the previous messages get lost and never acked.

This seem like a defect. Am I right?

Thanks in advance



--
Tim Bish

Re: [VOTE] Release Apache ActiveMQ Artemis 2.31.2

2023-10-27 Thread Timothy Bish 

On 10/27/23 07:16, Robbie Gemmell wrote:

Hi folks,

I would like to propose an Apache ActiveMQ Artemis 2.31.2 release.

This addresses a defect introduced in the recent 2.31.1 release.

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353776

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.2/

The Maven staging repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1379

If you would like to validate the release:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases

It is tagged in the git repo as 2.31.2.

Robbie

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Ran the binary broker and gave the web console a try
* Ran a the full set of AMQP of tests
* Ran the binary broker instance and executed examples from Qpid 
protonj2 against it


--
Tim Bish

Re: [DISCUSS] moving the artemis examples to their own git repository

2023-10-26 Thread Timothy Bish 

On 10/26/23 06:12, Robbie Gemmell wrote:

I'd like to move the artemis examples out of the main build+repo and
into a specific repo of their own.

There are a significant number of them, most of which rarely change,
and I think it would be nicer to have them sitting standalone. Having
them in-build somewhat complicates things as they are, and also quite
significantly slows down the release process currently. The repo/build
also tends to be marked for security issues that are only related to
the examples components (obviously we'd still want to update things in
the separate repo, but theyd at least be separate). The nightly
snapshot deploy job takes an age, mostly due to the examples. There is
really no reason we should be deploying them, so I'd also stop doing
that in a shift; I wouldnt actually envisage us releasing the examples
at all. We would set up the CI to continue building them similarly to
as we do now, theyd just sit separately.

Several other projects also use separate repos for their examples,
especially those with many of them. Specific cases I can think of
coming across most regularly are probably the multiple variants of
Camel, and Quarkus. On searching here at the ASF there do appear to be
various other projects that do this too:
https://github.com/orgs/apache/repositories?language==examples==all

Thoughts?

Robbie


+1

--
Tim Bish

Re: [VOTE] ActiveMQ Artemis 2.31.1 release

2023-10-25 Thread Timothy Bish 

On 10/25/23 16:33, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.31.1

This release contains bug fixes, improvements and component upgrades.

For a complete release refer to the JIRA release notes:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353642

Source and binary distributions can be found here:

https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.1


The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1377

If you would like to validate the release:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases

The release was tagged on git/github as 2.31.1



I will update the website with docs and related artifacts once the
release has passed


It is required to have at least 3 votes for this release to pass

[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


I'm already recording my +1 binding vote as part of this email..

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Ran the binary broker and gave the web console a try
* Ran a the full set of AMQP of tests
* Ran the binary broker instance and executed examples from Qpid 
protonj2 against it


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.16.7 release

2023-10-25 Thread Timothy Bish 

On 10/25/23 12:56, Robbie Gemmell wrote:

On Wed, 25 Oct 2023 at 15:35, Jean-Baptiste Onofré  wrote:

Hi guys,

I submit Apache ActiveMQ 5.16.7 release to your vote.
We did a single improvement in this release:
- improvement on OpenWire marshaller on Throwable class type

Here's the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12353758

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1375/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.7/

Git tag: activemq-5.16.7

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours or as soon as we will
have 3 binding votes.

Thanks !
Regards
JB

+1

I checked things out as follows:
- Verified the signature and checksum files.
- Checked for LICENCE + NOTICE files present in the archives.
- Checked headers in the source archive with: mvn apache-rat:check
- Ran the source build and the AMQP tests on JDK 8.
- Ran the Qpid JMS 2.4.0 HelloWorld against a broker started from the
tar.gz binary on JDK 8.

Robbie


+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Ran the binary broker and gave the web console a try
* Ran a selection of tests
* Ran the binary broker instance and executed examples from Qpid 
protonj2 against it


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.18.3 release

2023-10-25 Thread Timothy Bish 

On 10/25/23 01:37, Jean-Baptiste Onofré wrote:

Hi all,

I submit Apache ActiveMQ 5.18.3 release to your vote. This release is
a maintenance release on the 5.18.x series bringing:
- fix on destinations create when message is delayed
- fix on moving message to DLQ when produce via HTTP and TTL is reached
- improvement on KahaDB memory consumption
- improvement on OpenWire marshaller on Throwable class type
- implementation of JMS 2.x XA methods
- fix on JDK17+ support
- a lot of dependency updates
- and much more!

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12353355

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1373/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.3/

Git tag: activemq-5.18.3

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours or as soon as we will
have 3 binding votes.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Ran the binary broker and gave the web console a try
* Ran a selection of tests
* Ran the binary broker instance and executed examples from Qpid 
protonj2 against it


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.17.6 release

2023-10-25 Thread Timothy Bish 

On 10/25/23 04:01, Jean-Baptiste Onofré wrote:

Hi all,

I submit Apache ActiveMQ 5.17.6 release to your vote. This release is
a maintenance release on the 5.17.x series bringing:
- improvement on KahaDB memory consumption
- add additional fields on JMX Connection MBean
- improvement on OpenWire marshaller on Throwable class type
- a lot of dependency updates

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12353377

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1374/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.6/

Git tag: activemq-5.17.6

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours or as soon as we will
have 3 binding votes.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Ran the binary broker and gave the web console a try
* Ran a selection of tests
* Ran the binary broker instance and executed examples from Qpid 
protonj2 against it



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.31.0 (RC2)

2023-09-15 Thread Timothy Bish 

On 9/15/23 15:40, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.31.0 release.
This is the 2nd Respin of the release (RC2)

This was a large release overall with many improvements, and I'm proud
of what we accomplished on this release. Thanks for all who
contributed to this release by both raising JIRAs or contributing
changes:

* Improvements on the Artemis CLI:

   * Introduced a new feature, Artemis shell, as part of 2.31.0. When
you run ./artemis shell, a new terminal screen will help you navigate
through the CLI commands.
   * The shell terminal will also be presented when you run ./artemis.
   * You can use bash auto-complete. Run ./artemis auto-complete to
generate a bash script that provides auto-complete information for
your bash shell.
   * Added a CLI cluster verification tool to help you monitor your
broker topologies. Type ./artemis check cluster to access this
functionality.
   *  You can now use ./artemis queue stat to verify the message counts
on the entire cluster topology when clustering is in use.

AMQP Federation:
   * Added AMQP Federation support to broker connections.

* MQTT Session State Persistence:

* Paging JDBC Persistence performance was improved significantly

* The documentation was converted to Ascii Doc.

* Many other bug fixes and improvements, as usual.


The full JIRA release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353446

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.31.0

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.31.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1370

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

The release was tagged as 2.31.0 on git

I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1 Binding vote



+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source for license headers with 'mvn apache-rat:check'
* Ran the broker from the binary archive and exercised the web console
* Ran all the qpid-protonj2 client examples against the running broker
* Ran all the AMQP tests using: mvn clean install -DskipTests && cd 
tests/integration-tests/ && mvn test -Ptests 
-Dtest=org.apache.activemq.artemis.tests.integration.amqp.**


--
Tim Bish

Re: [DISCUSS] ActiveMQ 6.0.0 revisited

2023-09-12 Thread Timothy Bish 

On 9/11/23 17:14, Christopher Shannon wrote:

First, I realize that this thread is likely to cause a fight based on past
history and probably not go anywhere, but with the work being done
with Jakarta for AMQ 5.x I think it's time to at least bring up the
ActiveMQ 6.0 discussion.

With all the breaking changes currently targeted for version 5.19.x, such
as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty
upgrades and now potentially major OSGi changes, it makes zero sense to me
to have this next AMQ version as version 5.19.0 as it's completely
incompatible with the previous version 5.18.x. Users are likely going to be
in for a rude awakening when trying to upgrade and will be quite confused
as to why so much is different.

The Jakarta changes should really be a major version upgrade so that it's
much more clear to users that it's very different from the previous
version. Another major benefit of going with version 6.0 is that it frees
up the previous javax releases to continue on with 5.19 or 5.20 because we
will likely need to support the older javax releases for quite a while.

Also, from my point of view it seems pretty clear that the original goal
for Artemis to become AMQ 6.0.0 is never going to happen.  Artemis has had
its own branding and versioning for several years now and will likely
continue that way and not change so I don't really see that as a reason to
not bump AMQ 5.x to 6.x with all the major breaking changes.

Anyways, I figure there won't be much agreement here but thought I should
at least throw it out there before we go and release 5.19.x with such major
breaking changes.


+1

Seems like a good time to move to 6.x

--
Tim Bish

Re: Home for activemq-openwire

2023-08-23 Thread Timothy Bish 

On 8/23/23 13:11, Arthur Naseef wrote:

That sounds right.  My 2cents - it would be nice to figure out the closest
thing to a working flow that we can get, and then worry about cleanup.

Art


I spent a little time just to resurrect some knowledge on this, here's 
the basics


To run the generator in the ActiveMQ source tree you need to enable the 
profile in the activemq-client module for the openwire generator and use 
the generate sources goal:


   mvn -P openwire-generate generate-sources

This will at least try and generate the sources, the profile 
configuration tells it what the highest version is to generate in an ant 
task which needs to be moved to an ant target now as task is deprecated 
and will fall on its face until you do so.  Then it will actually try 
and do something, so if you added openwire v13 you'd change it or leave 
it at v12 and see if you can generate matching output and run the above 
command at which point it will fall on its face if you are on JDK 17 as 
the underlying javadoc types used by the generator are relocated to 
'jdk.javadoc.doclet' and renamed or refactored into something close but 
not quite the same.  So then you run it on JDK 11 and it will fall on 
its face with an NPE that I didn't bother to look deeper into but at 
least you have a starting point.


Likely the ancient annogen and gram stuff just won't work on a newer 
JDK, you could try running it on lower versions but the maven 
configuration will likely be unhappy as the compiler configuration is 
set to target 11 currently.


Hopefully that at least gets you pointed in the right direction, 
frustrating as it may be.





On Wed, Aug 23, 2023 at 4:30 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:


So maybe the activemq-openwire project should just be deprecated and go
away since it is not used or maintained.

It has been several years now but I'm pretty sure I just used the
activemq-openwire-generator 5.x module (as Tim mentioned) to generate the
latest v12 Openwire version that is in use today.

https://github.com/apache/activemq/commit/3953b9aaefaee914bdd0702f27aef47c021ceb27

On Tue, Aug 22, 2023 at 5:49 PM Arthur Naseef  wrote:


Thank you Tim.  That helps.

Art


On Tue, Aug 22, 2023 at 2:23 PM Timothy Bish 

wrote:

On 8/22/23 15:28, Arthur Naseef wrote:

I'd like to ask first to get some clarification.

Using the activemq-openwire project, I was able to get it to generate
openwire Java code, but that code did not exactly match the code in

the

activemq codebase.  It appeared to be mostly non-functional

differences,

such as packages being renamed, and import statements vs.

full-qualified

class names in the code.

Here are my questions:

 - What is the process for building and releasing a new version of

the

 openwire protocol?

There is no process other than running the generator in the ActiveMQ
tree if you can get it to run, I don't recall if there's anything
written down now that explains it as it has been years since I touched
it and my memory is foggy.  I vaguely recall there being an antrun
target in the pom file to run the generator so something like 'mvn
antrun:run'.

possibly some insights here:



https://github.com/apache/activemq-nms-openwire-generator/blob/d16ff371fecade87f97942cdf0174ab790bc999c/pom.xml#L172



 - Where are the NMS and C++ parts generated?  Are there others

generated

 as well?

I already answered this, please read my previous response.



 - How much manual intervention is needed in that process (e.g.

are

the

 java files generated, then copied and editted before being

committed

in the

 main project)?

I don't recall anymore if there is much intervention needed other than
generating the new marshallers but I do recall that KahaDB has some
settings that indicate which version it uses as a baseline.  I'd look

at

git commits in the 5.x code around the marshaller version code and see
what was touched in the commit.



Art


On Tue, Aug 22, 2023 at 12:22 PM Matt Pavlovich 

wrote:

Hi-

The activmeq-openwire project is currently hosted in a separate git
repository. The project is used to generate marshaller classes for

multiple

languages and would be suitable for supporting multi-broker openwire
support as well (5.x and Artemis). However, it does not appear to be

active

in any build lifecycle or toolchain for any of the ActiveMQ

projects.

I propose that we host the activemq-openwire project in the main 5.x

tree

for a couple reasons:

1. JDK changes and overall maintenance is easier from a single repo.

We

can add notes able compatibility or a README-VERSIONS.md to note

what

product releases go to which protocol versions, and when those

protocol

versions changed.

2. ActiveMQ 5.x uses openwire as its internal native protocol. It

makes

sense to host it there, especially of things like enhancements to

network

connector commands, which other client libraries and brokers usually

do

not

adopt

Re: Home for activemq-openwire

2023-08-22 Thread Timothy Bish 

On 8/22/23 15:28, Arthur Naseef wrote:

I'd like to ask first to get some clarification.

Using the activemq-openwire project, I was able to get it to generate
openwire Java code, but that code did not exactly match the code in the
activemq codebase.  It appeared to be mostly non-functional differences,
such as packages being renamed, and import statements vs. full-qualified
class names in the code.

Here are my questions:

- What is the process for building and releasing a new version of the
openwire protocol?


There is no process other than running the generator in the ActiveMQ 
tree if you can get it to run, I don't recall if there's anything 
written down now that explains it as it has been years since I touched 
it and my memory is foggy.  I vaguely recall there being an antrun 
target in the pom file to run the generator so something like 'mvn 
antrun:run'.


possibly some insights here: 
https://github.com/apache/activemq-nms-openwire-generator/blob/d16ff371fecade87f97942cdf0174ab790bc999c/pom.xml#L172




- Where are the NMS and C++ parts generated?  Are there others generated
as well?


I already answered this, please read my previous response.



- How much manual intervention is needed in that process (e.g. are the
java files generated, then copied and editted before being committed in the
main project)?


I don't recall anymore if there is much intervention needed other than 
generating the new marshallers but I do recall that KahaDB has some 
settings that indicate which version it uses as a baseline.  I'd look at 
git commits in the 5.x code around the marshaller version code and see 
what was touched in the commit.





Art


On Tue, Aug 22, 2023 at 12:22 PM Matt Pavlovich  wrote:


Hi-

The activmeq-openwire project is currently hosted in a separate git
repository. The project is used to generate marshaller classes for multiple
languages and would be suitable for supporting multi-broker openwire
support as well (5.x and Artemis). However, it does not appear to be active
in any build lifecycle or toolchain for any of the ActiveMQ projects.

I propose that we host the activemq-openwire project in the main 5.x tree
for a couple reasons:

1. JDK changes and overall maintenance is easier from a single repo. We
can add notes able compatibility or a README-VERSIONS.md to note what
product releases go to which protocol versions, and when those protocol
versions changed.

2. ActiveMQ 5.x uses openwire as its internal native protocol. It makes
sense to host it there, especially of things like enhancements to network
connector commands, which other client libraries and brokers usually do not
adopt fully.

3. There are planned enhancements coming that most likely require openwire
version bumps:
 - JMS 2.0 support features
 - Replication support (using Network Connectors)

Discuss.

Thank you,
Matt Pavlovich




--
Tim Bish

Re: Home for activemq-openwire

2023-08-22 Thread Timothy Bish 

On 8/22/23 15:21, Matt Pavlovich wrote:

Hi-

The activmeq-openwire project is currently hosted in a separate git repository. 
The project is used to generate marshaller classes for multiple languages and 
would be suitable for supporting multi-broker openwire support as well (5.x and 
Artemis). However, it does not appear to be active in any build lifecycle or 
toolchain for any of the ActiveMQ projects.


This is incorrect, the ActiveMQ 5.x code and others in C++ and .NET were 
generated using the module 'activemq-openwire-generator' in the 5.x 
source tree either directly (java) or by extension (CMS and NMS).


The CMS and NMS openwire bits had their own projects that extended the 
in-built generator module to create their native openwire marshallers 
and did not use the native language bits in the broker codebase (those 
were contributed by other users for also abandoned client impls).  Any 
native language client would likely do this as their marshaller code and 
the openwire commands would generally be very specific to the library 
and its implementation details.


The CMS generator project is here for context: 
https://github.com/apache/activemq-cpp/blob/master/activemq-cpp-openwire-generator/pom.xml


I believe there is a separate git repo for the NMS openwire client as 
that is also a Java based tool.


I'd doubt that any of these would work today as they relied on hacks 
that if I recall correctly no longer work with modern JDKs at least not 
as they stand now.  You will likely need to do some work to get them 
running (I can't even recall now the commands needed to do it in the past).




I propose that we host the activemq-openwire project in the main 5.x tree for a 
couple reasons:

1. JDK changes and overall maintenance is easier from a single repo. We can add 
notes able compatibility or a README-VERSIONS.md to note what product releases 
go to which protocol versions, and when those protocol versions changed.

2. ActiveMQ 5.x uses openwire as its internal native protocol. It makes sense 
to host it there, especially of things like enhancements to network connector 
commands, which other client libraries and brokers usually do not adopt fully.

3. There are planned enhancements coming that most likely require openwire 
version bumps:
 - JMS 2.0 support features
 - Replication support (using Network Connectors)

Discuss.

Thank you,
Matt Pavlovich



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.30.0

2023-07-21 Thread Timothy Bish 

On 7/21/23 09:54, Justin Bertram wrote:

I would like to propose an Apache ActiveMQ Artemis 2.30.0 release.

This is mainly a bug-fix release with a few small improvements and a
handful of dependency upgrades.

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12353357

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.30.0.html

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.30.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1367

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

The source tag:
https://github.com/apache/activemq-artemis/tree/2.30.0

I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1


Justin


+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source for license headers with 'mvn apache-rat:check'
* Ran the broker from the binary archive and exercised the web console
* Ran all the qpid-protonj2 client examples against the running broker
* Ran all the AMQP tests using: mvn clean install -DskipTests && cd 
tests/integration-tests/ && mvn test -Ptests 
-Dtest=org.apache.activemq.artemis.tests.integration.amqp.**



--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.18.2 release

2023-06-30 Thread Timothy Bish 

On 6/28/23 01:44, Jean-Baptiste Onofré wrote:

Hi,

I submit Apache ActiveMQ 5.18.2 release to your vote. This release is
a maintenance release on the 5.18.x series bringing:
- fix potential NPE when removing consumer with selector
- fix composite consumers in a NoB
- fix memory leak on the STOMP transport when client unsubscribe
- a bunch of dependency updates

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12353099

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1283/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.2/

Git tag: activemq-5.18.2

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB


+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Built from source and ran the tests, ignored known broken test
* Started a broker instance from the binary and checked webconsole worked.

--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.17.5 release

2023-06-30 Thread Timothy Bish 

On 6/28/23 09:40, Jean-Baptiste Onofré wrote:

Hi guys,

I submit Apache ActiveMQ 5.17.5 release to your vote. This release is
a maintenance release on the 5.17.x series bringing:
- fix on stale queues when a connection is long to shutdown
- fix on KahaDB where the db files may be larger than the maxLength
configuration
- fix on composite consumers on NoB
- fix memory leak on STOMP transport when clients unsubscribe
- a bunch of dependency updates

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12352888

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1284/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.5/

Git tag: activemq-5.17.5

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Built from source and ran the tests, ignored known broken test
* Started a broker instance from the binary and checked webconsole worked.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.29.0

2023-06-16 Thread Timothy Bish 

On 6/14/23 19:39, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.29.0 release.

This is a representative workload with 126 JIRAs and 200+ commits with
a diverse number of committers. Thanks to all who contributed to this
big release.


The release notes can be found here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352880=12315920


Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.29.0


Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.29.0


The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1279

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The version has been tagged on git as '2.29.0'

I will update the website after the vote has passed.



[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1


I will keep the Vote open until monday, US EST morning, on June 19th



+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Exercised the web console with a the binary broker package
* Ran some Qpid protonj2 examples against the running broker
* Ran some of the broker tests from the source archive.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.18.1 release

2023-04-11 Thread Timothy Bish 

On 4/11/23 05:26, Jean-Baptiste Onofré wrote:

Hi,

I submit Apache ActiveMQ 5.18.1 release to your vote. This release
fixes activemq-client-jakarta where the META-INF/services file was
missing in the artifact.

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12352969

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1278/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.1/

Git tag: activemq-5.18.1

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB




+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source headers using 'mvn apache-rat:check'
* Ran a selection of the unit tests
* Ran the broker from the binary archive and exercised the web console
* Created a simple maven project to send a hello world message using the 
Jakarta client dependency (TCP only no SSL).



--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.18.0 release

2023-03-23 Thread Timothy Bish 

On 3/19/23 13:26, Jean-Baptiste Onofré wrote:

Hi,

After several weeks of work, I'm glad to submit ActiveMQ 5.18.0 to
your vote. This release is a major milestone for ActiveMQ bringing
major changes:
- JMS 2 API support (client)
- support Jakarta namespace (client)
- a lot of dependency updates and fixes
- and much much more!

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12351380

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1275/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.0/

Git tag: activemq-5.18.0

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified license headers in source using 'mvn apache-rat:check'
* Built from source and ran a portion of the test suite
* Spun up a broker from the binary archive and exercised the web console
* Ran the Qpid protonj2 client example against the binary broker instance.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.17.4 release

2023-02-23 Thread Timothy Bish 

On 2/22/23 03:06, Jean-Baptiste Onofré wrote:

Hi,

I submit ActiveMQ 5.17.4 to your vote. This release includes several
fixes, improvements and a lot of dependency updates, especially:
- add JOLOKIA_CONF env variable in wrapper configuration
- potential race condition in the store while creating new destinations
- fix reentrant lock in the broker configuration runtime
- upgrade to xstream 1.4.20
- upgrade to Spring 5.3.25
- and much more!

You can a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12352481

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1270/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.4/

Git tag: activemq-5.17.4

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Rand the broker from the binary archive and exercised the web console
* Built from source archive and ran some of the test suite


--
Tim Bish

Re: [VOTE] Release activemq-nms-openwire 2.0.1-rc1

2023-02-06 Thread Timothy Bish 

On 2/4/23 12:54, Havret wrote:

Hi all,

I have put together a release of activemq-nms-openwire, please check it
and vote accordingly. Huge thanks to Łukasz Cygan for his help in resolving
the issue identified in version 2.0.0.

This release contains the following change:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201=12352889

The files can be grabbed from:
https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-openwire/2.0.1-rc1/

Regards,
Chris

Here's mine +1 (binding)


+0

It doesn't appear that the project NOTICE files were updated with the 
current year prior to this release candidate.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.28.0

2023-01-31 Thread Timothy Bish 

On 1/31/23 10:18, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.28.0 release.

I would like to highlight the following changes in this release:

- Page counting improved. We no longer store counters in the journal
simply relying on paging itself for that
- We implemented a way to sync mirror from AMQP Broker Connections

For a complete release notes:
https://activemq.apache.org/components/artemis/download/release-notes-2.28.0

The git commit 
report:https://activemq.apache.org/components/artemis/download/commit-report-2.28.0


Source and binary staged distributions:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.28.0

The maven repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1268

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The current release candidate is tagged on the git repository as 2.28.0

I will update the website after the vote has passed

[ ] +1 approve this release
[ ] -1 disapprove (and why)
[ ] +0 no opinion (I would appreciate a reason why if this is your
choice as well)

+1

* Validated signatures and checksums
* Verified license files and notices in archives
* Checked source license headers using 'mvn apache-rat:check'
* Ran the broker from the binary archive and exercised the web console
* Built from source and ran the AMQP tests
* Ran the protonj2 examples against the broker instance
* Ran the proton-dotnet examples against the broker instance


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.17.3

2022-11-29 Thread Timothy Bish 

On 11/29/22 10:31, Jean-Baptiste Onofré wrote:

Hi all,

I submit the ActiveMQ 5.17.3 release to your vote.

This release includes 32 fixes and improvements, especially:
- Fix ActiveMQ Console on Karaf 4.4.x
- Fix Jolokia startup on Windows platform
- Upgrade to Spring 5.3.23
- Upgrade to Jackson 2.14.0
- and much more!

Please take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12352201

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1267/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.3/

Git tag: activemq-5.17.3

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards

+1

* Verified signatures and checksums
* Verified license and notice files in archives
* Checked source headers using 'mvn apache-rat:check'
* Built from source and ran some of the tests
* Ran a broker using the binary archive and tested some Qpid protonj2 
and proton-dotnet examples

* Exercised the web console exposed from this binary instance.

--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.27.1 release

2022-11-29 Thread Timothy Bish 

On 11/28/22 16:54, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.27.1 release


This is a bug fix release,

I would like to highlight these 3 bug fixes:

- AMQP Large Message over Bridges were broken
- Rollback of massive transactions would take a long time to process
- Improvements to auto-create and auto-delete queues.

For a full release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352610=12315920


Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.27.1


Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.27.1/


The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1266

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.27.1


I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1 (binding)




+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Ran mvn verify on archives source
* Ran the AMQP test suite with 'mvn clean install -DskipTests && cd 
tests/integration-tests/ && mvn -Ptests 
-Dtest=org.apache.activemq.artemis.tests.integration.amqp.** test'

* Exercised the web console in Firefox
* Ran examples from Qpid protonj2 and proton-dotnet against the binary 
broker instance.



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.27.0

2022-11-09 Thread Timothy Bish 

On 11/8/22 21:33, Justin Bertram wrote:

I would like to propose an Apache ActiveMQ Artemis 2.27.0 release.

New and noteworthy items in 2.27.0:

  - Fix for CVE-2022-42889 (Apache Commons Text vulnerability)
  - Logging implementation moved to Apache Log4j 2 (internally using SLF4J)
  - New upgrade command to help users migrate from previous versions

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12352246

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.27.0

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.27.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1265

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

The source tag:
https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/2.27.0

I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1


Justin


+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers with 'mvn apache-rat:check'
* Ran a broker from the binary archive and exercised the web console
* Ran the AMQP tests in the integration tests
* Ran the Hello World example from protonj2 against the binary broker 
install
* Ran the Hello World example from proton-dotnet against the binary 
broker install



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.26.0 release

2022-09-21 Thread Timothy Bish 

On 9/21/22 16:23, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.26.0 release.


We removed ActiveMQ Artemis Rest, (which was already non functional)
as part of this release.
And other improvements and bug fixes.


The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352297=12315920

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.26.0

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.26.0

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1262


In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

The source tag is 2.26.0 on git, commit
2d7b1a3ef7613dab68aeeb667f5b5eca37743b94:
https://github.com/apache/activemq-artemis/releases/tag/2.26.0

The source tag:

https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/


I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here is my +1 Binding vote





+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source license headers with 'mvn apache-rat:check'
* Built from source and ran the AMQP tests using
'mvn clean install -DskipTests && cd tests/integration-tests/ && mvn 
test -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**'
* Ran a broker instance from the binary archive and exercised the web 
console

* Ran all Qpid proton-dotnet examples against the running broker instance
* Ran the Qpid protonj2 hello world example against the broker instance.


--
Tim Bish

Re: [VOTE] ActiveMQ Artemis 2.25.0 Release

2022-09-01 Thread Timothy Bish 

On 8/31/22 12:28, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.25.0 release.

This JIRA improved flow control from paging preventing Out Of Memory
issues when there's a bad consumer without flow control (ARTEMIS-3943
(Thank you Anton Roskvist)).

Among other fixes and improvements.


The whole release notes could be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352143=12315920


The commit report:
https://activemq.apache.org/components/artemis/download/commit-report-2.25.0

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.25.0

The Maven repository is here:

https://repository.apache.org/content/repositories/orgapacheactivemq-1261


In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:

https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=commit;h=fb1b362b473cad51ae5d05a897be02b1fa8461d4

The tag is 2.25.0 on git.


I will update the website after the vote has passed.


[ ] +1 approve the release as Apache Artemis 2.4.0
[ ] -1 disapprove (and reason why)


Here's my +1 Binding

+1

* Validated signatures and checksums
* Verified source license headers with 'mvn apache-rat:check'
* Ran the broker from the binary archive and exercised the web console
* Built from source and ran the AMQP test suite using
   'mvn clean install -DskipTests && cd tests/integration-tests/ && mvn 
test -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**'
* Ran the Qpid protonj2 hello-world example against the binary broker 
instance


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.24.0

2022-07-27 Thread Timothy Bish 

On 7/26/22 14:30, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.24.0 release

There are two features added as part of this release:

- Paging does not use soft cache any longer. As a matter of fact we
don't have any caching now.. we just read from files straight to
Queues
- Mirror now supports encryption of password

and several fixes, mainly in AMQP Mirroring

Thanks for all the contributions on this release!



The release notes is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351822=12315920


The git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.24.0



Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.24.0


The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1259


In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://github.com/apache/activemq-artemis/releases/tag/2.24.0


I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1 Binding






+1

* Validated signatures and checksums
* Verified license and notice files present
* Verified source license headers using apache-rat
* Built from source and ran the AMQP tests
* Ran the binary broker instance and exercised the web console.


--
Tim Bish

Re: [DISCUSS] Remove shaded client JARS

2022-07-26 Thread Timothy Bish 

+1

Removing them seems valid given the issues noted.

On 7/26/22 12:18, Robbie Gemmell wrote:

I think removing them would be good for various reasons inc all you noted below.

On Tue, 26 Jul 2022 at 14:34, Clebert Suconic  wrote:

We currently deploy these following shaded uber jars with ActiveMQ Artemis.

artemis-jms-client-all
artemis-core-client-all
artemis-jakarta-client-all

We are in the process of removing jboss-logging, and replacing it by
SLF4j /LOG4J on a separate branch, and we will probably make a switch
on the branch as 3.0.

I never really liked these shaded jars as part of the distribution. I
would be inclined to remove them on a switch for 3.0 anyways, and now
we are having a build issue,
as they will fail (on a second build) shading apache-commons-logging:

ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:3.3.0:shade (default) on
project artemis-core-client-all: Error creating shaded jar: duplicate
entry: 
META-INF/services/org.apache.activemq.artemis.shaded.org.apache.commons.logging.LogFactory
-> [Help 1] [ERROR]  [ERROR] To see the full stack trace of the
errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using
the -X switch to enable full debug logging. [ERROR]  [ERROR] For more
information about the errors and possible solutions, please read the
following articles: [ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]  [ERROR] After correcting the problems, you can resume the
build with the command [ERROR]   mvn  -rf
:artemis-core-client-all




Also, they add about 20MB to our distribution, and more 10MB for the
core-client-all that's not on the distro but it is on maven repo.

This is a common trend with other projects. Netty stopped producing a
netty-all and is offering a pom. Jetty did the same thing.. and There
are a lot of issues introduced by an "all client".


So, even though we could fix the build, these JARs are never tested as
part of the testsuite or anything It's like playing with the
odds...  and they are huge on the distribution as they will all
include copies of Netty.


I would really like to remove these JARs and I think it would be a
great improvement to do so.

These POMS are already defining all the dependencies anyway. Any user
who wants to have a shaded jar would just be able to shade it
themselves as part of their project.


If anyone  have a strong feeling about keeping them we would need:

- your opinion (why we keep them on 3.0)
- Help fixing the build on new-logging
- Help with adding smoke tests for these jars.


anyone?



--
Tim Bish

Re: [VOTE] ActiveMQ Artemis Native 2.0.0 release (RC2)

2022-07-14 Thread Timothy Bish 

On 7/12/22 15:49, Clebert Suconic wrote:

I would like to propose an ActiveMQ Artemis Native 2.0.0 release


For those who are not familiar, this is the Native Layer in Artemis
responsible for the integration on Linux and Libaio.


I have been working on some logging changes with Robbie Gemmel, and
Artemis Native 2.0.0 is now using SLF4J. This Module will be a
requirement for ActiveMQ Artemis to move forward with SLF4J.



The source distribution is here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/2.0.0/


The Maven staged repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1257


The git tag is here:
https://github.com/apache/activemq-artemis-native/releases/tag/2.0.0


the release notes is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348395




[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1 binding





+1

* Built and ran tests
* Verified license and notice files


--
Tim Bish

Re: [VOTE] ActiveMQ Artemis 2.23.1

2022-06-15 Thread Timothy Bish 

On 6/14/22 16:58, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.23.1 release

This is a small release following up where I added a fix for the following bug:

https://issues.apache.org/jira/browse/ARTEMIS-3856 - Failed to change
channel state to ReadyForWriting :
java.util.ConcurrentModificationException



The release notes is here:
https://activemq.apache.org/components/artemis/download/release-notes-2.23.1

The commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.23.1

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.23.1

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1254

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.23.1

I will update the website after the vote has passed.



[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here is my +1 Binding vote.

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified license headers in source using apache rat check
* Rand the binary broker release and tested the web console
* Built from source and ran the AMQP test suite
* Ran some Qpid proton-dotnet examples against the binary release broker 
instance



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.23.0

2022-06-08 Thread Timothy Bish 

On 6/7/22 15:05, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.23.0 release.

As part of this release I would like to highlight the addition of
Jakarta 10 to the supported APIs.



The release notes can be found here:
https://activemq.apache.org/components/artemis/download/release-notes-2.23.0

The git commit report:
https://activemq.apache.org/components/artemis/download/commit-report-2.23.0



Source and binary distributions can be found here:

https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.23.0

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-


In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.23.0

or the equivalent tag on github:
https://github.com/apache/activemq-artemis/releases/tag/2.23.0


I will update the website after the vote has passed.



[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here is my +1 Binding Vote
.

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers using 'mvn apache-rat:check'
* Ran the broker using the binary archive and executed qpid-protonj2 and 
qpid-proton-dotnet examples against it

* Built from source archive and ran the AMQP test suite


--
Tim Bish

Re: [VOTE] Terminology to replace master/slave in ActiveMQ

2022-05-06 Thread Timothy Bish 

On 5/6/22 02:26, Tetreault, Lucas wrote:

[ ] Primary/Backup


[+1] Primary/Backup

--
Tim Bish

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

2022-05-03 Thread Timothy Bish 

On 4/29/22 16:36, Clebert Suconic wrote:

For a while, I thought it would be nice to remove jboss-logging from
artemis and use a generic logger. (SLF4J, Log4j, commons.. whatever..
it's all orthogonal and transparent to this discussion, we can decide
that at a later point).


One of the issues we had while making the move would be the generated
error codes out of the Log Processor.


So, I put together a prototype here that would generate code based on
an interface and that could use whatever logger we choose. I will try
to never remove the branch for future reference:


https://github.com/clebertsuconic/activemq-artemis/tree/prototype-log-processor



the Log processor would read the annotations and generate the code:

https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-log-processor/src/main/java/org/apache/activemq/artemis/logprocessor/processor/LogProcessor.java




A testcase here would show how such processing would work:

https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-log-processor/src/test/java/org/apache/activemq/i18n/test/SimpleBundleTest.java


I have added some code on the artemis-server, trying to simulate what
we would do in "real life":


https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQServerNewLogger.java



This test here is making a call to the NewLogger, just to show how
processing would work. Everything would work just like it would now:

https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-server/src/test/java/org/apache/activemq/artemis/core/TestSample.java




I would appreciate some feedback if this is a good way forward or not...

(please let's not diverge on what logging framework we are choosing
now... that's a separate discussion).






+1

Agree with others that slf4j would be a good choice

--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.16.5 release

2022-04-29 Thread Timothy Bish 

On 4/29/22 05:01, Jean-Baptiste Onofré wrote:

Hi guys,

I submit the ActiveMQ 5.16.5 release to your vote.

This release is a maintenance release on the 5.16.x series including:
- fix on configuration when wrapper is used
- fix memory lead on temp store
- avoid potential NPE when starting ActiveMQ
- add missing Jetty continuation artifact and use of atomic jetty
artifacts instead of the uber server one
- bunch of dependency updates

NB: 5.16.5 will be announced as the last release on the 5.16.x series,
5.16.x will go EOL after this release.

Please take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12351117

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1252/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.5/

Git tag: activemq-5.16.5

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB
.

+1

* Validated signatures and checksums
* Verified license and notice files
* Checked source license headers with 'mvn apache-rat:check'
* Built from source and ran a portion of the test suite
* Exercised the web console to check it works
* Ran some java and .NET AMQP examples against the binary broker instance.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.22.0

2022-04-28 Thread Timothy Bish 

On 4/28/22 12:24, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.22.0 release.


There are no new features on this release, however there are many
improvements and bug fixes.

In particular there's a default change on cluster connections where we
now use 1MB bytes for flow control, avoiding Out Of Memory exception
on situations with high latency networking:

* ARTEMIS-3083 Set a default producer-window-size on cluster connection


There are many other improvements and bug fixes and the full release
notes is available here for more information:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12351488


Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.22.0


Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.22.0

The Maven staged repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1251


In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:

https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.22.0


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1 (Binding) vote



I should keep this release open for 72 Hours, and I'm not going to
count the weekend as business hours. That means I will keep this
release open until at least May-3rd, Noon USA EST.

+1

* Validated signatures and checksums
* Verified license and notice files
* Checked source licenses with 'mvn apache-rat:check'
* Built from source and ran the AMQP test suite
* Ran the broker from the binary archive and tested the web console
* Ran some AMQP client examples against the running broker instance.


--
Tim Bish

Re: [VOTE] Release activemq-nms-api 1.8.1-rc1

2022-04-27 Thread Timothy Bish 

On 4/25/22 13:40, Havret wrote:

Hi all,

I have put together a release of activemq-nms-api, please check it and vote
  accordingly.

This release contains a single bugfix[1] by Iuliia Fatkullina! Thank you!

The files can be grabbed from:
https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-api/1.8.1-rc1/

Regards,
Krzysztof

[1]: https://issues.apache.org/jira/browse/AMQNET-745

I took a brief look at the release, the NOTICE file appears to be rather 
out of date (2019).  Haven't looked deeper yet.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.17.1 release

2022-04-25 Thread Timothy Bish 

On 4/25/22 10:21, Jean-Baptiste Onofré wrote:

Hi guys,

I submit the ActiveMQ 5.17.1 release to your vote.

This release is an important release on the 5.17.x series, bringing
major changes:
- upgrade to Spring 5.3.19, fixing Spring4shell vulnerability (even if
ActiveMQ is not directly impacted)
- XBean 4.21 (supporting Spring 5.x) and ASM 9.3 for better Java 18+ support
- and much much more

Please take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12351348

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1250/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.1/

Git tag: activemq-5.17.1

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source license headers using 'mvn apache-rat:check'
* Built from source and ran a selection of tests in the test suite
* Spun up a broker from the binary archive and exercised the web console
* Ran some examples from the protonj2 AMQP client against the broker.


--
Tim Bish

Re: Making APLO Jira Project read only

2022-04-06 Thread Timothy Bish 

+1 from me

On 4/6/22 16:12, Robbie Gemmell wrote:

Sounds good to me.

On Wed, 6 Apr 2022, 20:34 Christopher Shannon, <
christopher.l.shan...@gmail.com> wrote:


Another one I noticed that can probably be closed is:
https://issues.apache.org/jira/projects/BLAZE

On Wed, Apr 6, 2022 at 3:19 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:


I am planning to submit a ticket to infra to make APLO read only since

the

project has been deprecated for over 4 years and no longer supported or
worked on (and the git repo is read only already). At this point we only
get spam so unless someone objects I was just going to use lazy
consensus and put in the ticket. I also just went through and did a bulk
update and closed all existing issues.



--
Tim Bish

Re: nms-amqp repo default branch rename

2022-04-04 Thread Timothy Bish 

On 4/4/22 13:12, Havret wrote:

Sure, do you have the link to the previous ticket so I can clone it?



https://issues.apache.org/jira/browse/INFRA-21495


Thanks,
Havret

On Mon, Apr 4, 2022 at 5:19 PM Robbie Gemmell 
wrote:


About a year ago we requested that Infra rename the default branches
to 'main' for the various git repositories. I have just noticed from
some push notification mails that the
https://github.com/apache/activemq-nms-amqp repository was missed out,
its branch was not renamed.

I think we should raise another INFRA JIRA to get its default branch
renamed and align it with the others. Can one of the NMS maintainers
take care of this please, as infra will want verification that goes ok
etc?

Robbie



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.21.0

2022-03-23 Thread Timothy Bish 

On 3/22/22 17:32, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.21.0 release.

We added these new features as part of 2.21.0:

[ARTEMIS-3522] - Implement performance tools to evaluate throughput
and Response Under Load performance of Artemis
[ARTEMIS-3638] - MQTT 5
[ARTEMIS-3670] - Diverting to multiple addresses
[ARTEMIS-3685] - Reloading bridges
[ARTEMIS-3686] - Example integrating OpenTelemetry
[ARTEMIS-3720] - Max number of messages as a deciding factor for Paging


The complete release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351083=Text=12315920

The git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.21.0

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.21.0/

The maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1249

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.21.0


I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1 (binding)

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Verified source licenses with 'mvn apache-rat:check'
* Built from source and ran some of the AMQP test suite
* Ran the binary broker package instance and exercised the protonj2 
examples against it


--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.17.0 release (take #2)

2022-03-10 Thread Timothy Bish 

+1

* Validated signatures and checksums
* Verified license and notice files in archives
* Checked source for license headers using apache-rat
* Built from source and ran a sampling of the tests
* Spun of the broker from the binary archive and tested some with the 
Web Console



On 3/10/22 00:10, Jean-Baptiste Onofré wrote:

Hi guys,

I submit ActiveMQ 5.17.0 release (take #2) to your vote. Compared to the
first attempt, we fixed geronimo jar version and shading of
activemq-client, activemq-pool, activemq-jms-pool artifacts.

This release is an important milestone in ActiveMQ roadmap, including 200
issues, especially:
- support Spring 5.x
- support log4j 2.x (2.17.1)
- JDK 11+ support for both build and runtime
- remove of activemq-camel component (replaced by camel-activemq and
camel-jms components)
- remove leveldb
- tons of fixes and dependency updates

Please take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12346476

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1248/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.17.0/

Git tag: activemq-5.17.0

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB



--
Tim Bish

Re: [PROPOSAL] ActiveMQ 5.17.0 end of this week

2022-02-22 Thread Timothy Bish 
+1 from me, the JMS 2.0 stuff can bake a bit longer and be in the next 
release


On 2/22/22 09:23, Robbie Gemmell wrote:

It is very much OK with me.

(You'll most often see me moaning about not releasing enough, and
putting too much in single releases, rather than the reverse).

On Tue, 22 Feb 2022 at 14:17, Jean-Baptiste Onofré  wrote:

I agree.

@Matt @Robbie @Tim is it ok for you to have 5.17.0 with Spring5,
log4j2, JDK11 and include JMS2 in 5.18.0 that can happen quickly ?

Regards
JB

On Tue, Feb 22, 2022 at 3:09 PM Christopher Shannon
 wrote:

I'm +1 on moving forward without JMS 2.0 until 5.18.0.  The reality is there is 
no consensus to keep it in 5.17.0. There are multiple people who do not want to 
include it in 5.17.0 so it's time to move on without. We also need to revert 
the commits from https://issues.apache.org/jira/browse/AMQ-7309 as there is no 
reason to include that now.

So I say go ahead with the release and vote (after wrapping things up including 
reverting that AMQ-7309 JMS 2 stuff).

I'm pretty tired of the back and forth and fighting over version numbers to be 
honest and just want to move on. It's not productive to keep arguing anymore 
over a version...5.18.0 can literally go out whenever we want.

On Tue, Feb 22, 2022 at 8:50 AM Jean-Baptiste Onofré  wrote:

Hi guys,

Quick update about 5.17.0 release:

- I fixed/squash log4j2 update PR
(https://github.com/apache/activemq/pull/662). I think it's OK (I'm
waiting for the end of Jenkins).
- I'm creating Apache POM 25 update PR
- I'm creating Spring 5.3.16 update PR

So, ActiveMQ 5.17.0 is almost ready from this standpoint.

As I would like to start the vote asap, It would be great to act about
JMS2. Do you want me to start with different options ?

Regards
JB

On Mon, Feb 21, 2022 at 5:55 AM Jean-Baptiste Onofré  wrote:

Hi guys,

I worked on the log4j2 update PR this weekend, fixing almost all unit
tests using a custom appender. I just have to fix the
activemq-web-demo test and squash, and the PR will be good to be
merged. I will do that today.

Then, later today and tomorrow I will work on using jetty modules
instead of jetty-all and update to Jetty 9.4.45.

I will do a pass on Jira and PRs, especially the ones from Matt. @Matt
can you please ping me on slack to check together the status of the
PRs ?

Regarding this, I would like to submit 5.17.0 to vote this Thursday if
there are no objections.

Regards
JB



--
Tim Bish

Re: [PROPOSAL] ActiveMQ 5.17.0 end of this week

2022-02-21 Thread Timothy Bish 

On 2/21/22 08:12, Christopher Shannon wrote:

+1 to go with 5.17.0 without JMS 2.0

I think we should just wait for all the JMS 2.0 stuff for 5.18.0. We
shouldn't even include the new dependency as it would be kind of confusing
as it wouldn't implement anything. We can easily document that if someone
wants to use the JMS 2.0 jar it's no problem to use it with excluding the
1.1. and using the new jar (I've been doing this for years) and just not
call the new methods.


+1




5.18.0 doesn't have to take years longer, it can go out whenever we want (1
month, 3 months, etc). So I think just reverting all the JMS 2.0 and
rolling with the other updates makes sense.

On Mon, Feb 21, 2022 at 7:58 AM Jean-Baptiste Onofré 
wrote:


Hi guys,

I agree about the change, and it was not what we agreed on the mailing
list.

The initial plan for 5.17.0 about JMS 2.0 is "just" to update the
client side to support JMS 2.0 and throw UnsupportedOperationException
for JMS 2.0 specific method.
I think it's good enough for 5.17.0 to support the first JMS 2.0 round.

More than that (client/broker side) should go in 5.18.0 IMHO.

Regards
JB

On Mon, Feb 21, 2022 at 1:35 PM Robbie Gemmell 
wrote:

Finally doing a 5.17.0 release sounds good.

That said, I dont personally think
https://github.com/apache/activemq/pull/729 is ready for inclusion in
a release though, even with an '-rc1' adorned version number
previously suggested but apparently no longer planned, since even as a
'first phase' it is surprisingly incomplete, adding some of the JMS 2
'simplified API' but not even doing much of the basic JMS 1.1 level
functionality within it, like setting a MessageListener on a
JMSConsumer, or creating a durable subscriber (non-shared), or
JMSContext's acknowledge() method for doing client-ack (presumably the
message method works though), etc.

It also just seems very odd to even think about just *starting* to
including stuff like that on main within a couple days of intending to
do a release thats nearing being *years* in the making, and getting
describe to users as '2-3 weeks' for way over a year now, including
multiple times in the last few months.

For me, the most obvious idea at this point would actually be for
5.17.x to be branched and proceed without this. Theres a load of stuff
in it already that is long overdue like the JDK11 build etc. I would
go so far as to say the prior API jar change from early November
(https://github.com/apache/activemq/pull/682) should also be
effectively reverted, it makes no sense to me on its own. Then all of
this stuff then worked on towards a 5.18.x release that actually
implements and tests things to a reasonable level thats less likely to
see even trivial use cases fail to work.

Robbie

On Mon, 21 Feb 2022 at 04:55, Jean-Baptiste Onofré 

wrote:

Hi guys,

I worked on the log4j2 update PR this weekend, fixing almost all unit
tests using a custom appender. I just have to fix the
activemq-web-demo test and squash, and the PR will be good to be
merged. I will do that today.

Then, later today and tomorrow I will work on using jetty modules
instead of jetty-all and update to Jetty 9.4.45.

I will do a pass on Jira and PRs, especially the ones from Matt. @Matt
can you please ping me on slack to check together the status of the
PRs ?

Regarding this, I would like to submit 5.17.0 to vote this Thursday if
there are no objections.

Regards
JB



--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.16.4 release (take #3)

2022-02-14 Thread Timothy Bish 

On 2/11/22 13:47, Jean-Baptiste Onofré wrote:

Hi all,

I submit Apache ActiveMQ 5.16.4 release to your vote (take #3).

This release includes important fixes and updates on the 5.16.x
series, especially:
- log4j 1.x has been replaced by reload4j including the latest security fixes
- fix OSGi imports
- fix couple of warnings/issues on JDK16
- fix stack trace display on transports
- better secure web console
- several dependency updates
- and much more!

Please take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12350483

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1246/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.4/

Git tag: activemq-5.16.4

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Verified license and notice files present
* Check source licenses using apache rat
* Built from source and ran some of the unit tests
* Spun up the broker from the binary package and exercised the web console.




--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.19.1

2022-01-28 Thread Timothy Bish 

On 1/26/22 15:08, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.19.1 release.


This is a maintenance release on top of 2.19.0 that includes a few bug fixes.

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12351260

The git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.19.1


I have generated a XREF report here, where you can follow commits that
were cherry-picked from master into 2.19.1.. Look for the column XREF
on the report:
https://activemq.apache.org/components/artemis/download/cherry-pick-report-2.19.1


Source and binary distributions are found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.1/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1241


In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.19.1

I will update the website after the vote has passed.



[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
.

+1

* Validated signatures and checksums
* Verified license and notice files present
* Verified source license with 'mvn apache-rat:check'
* Ran the binary broker and exercised the web console
* Built from source and ran the AMQP test suite in the integration tests
* Ran the protonj2 hello world example against the binary broker release

--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.20.0

2021-12-16 Thread Timothy Bish 

On 12/15/21 12:22 PM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.20.0 release...


There is a few improvements and bug fixes on this release, there's one
feature added:

[ARTEMIS-2097] - Pause and Block Producers

This is also the first release where we are requiring JDK 11+. JDK 1.8
won't work on this release any longer.


You can access the release notes and the git report here:
https://activemq.apache.org/components/artemis/download/release-notes-2.20.0


The source and binary distributions:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.20.0

The maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1240

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.20.0


I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


This also records my +1 (Binding) vote.

I will keep this VOTE open until Monday Dec-20th 12:30 PM US EST time
as the usual 72 hours for the release would take us to a Saturday.


+1

* Validated signatures and checksums
* Verified artifacts contain license and notice files
* Verified source license headers with Apache Rat
* Built from source and ran the AMQP test suite
* Ran the binary broker distribution and exercised the web console.
* Ran the protonj2 client hello world example against the broker instance.


--
Tim Bish

Re: log4j (CVE-2021-44228) vulnerability and ActiveMQ 5.8.0

2021-12-14 Thread Timothy Bish 

On 12/14/21 3:05 PM, Justin Bertram wrote:

Yes, I think the same. As already noted, ActiveMQ 5.8.0 doesn't use any
version of the vulnerable library (i.e. Log4j2 <=2.14.1).


It's also worth noting that ActiveMQ 5.x uses slf4j as the primary 
logging facade so if you don't like the default log4j used by the 
packaged broker you are free to substitute in another logging binding 
that meets your needs.






Justin

On Tue, Dec 14, 2021 at 1:46 PM Martin Piattini 
wrote:


Hi
Looking more details the vulnerability is in:

Library versions Log4j 2.x (below than 2.15.0) are affected
Library versions Log4j 1.x are not affected
The issue has been resolved in log4j version 2.15.0 or higher

And ActiveMQ 5 suppouse use: Log4j 1.2.x then is not affected

Do you think the same?

Thanks
Regards
Martin






Martin Piattini Velthuis, PMP - SAP CPI/PO/PI Consultant

PK – the Experience Engineering firm

M + 54 9 11 5644-8108

mpiatt...@pkglobal.com




De: Martin Piattini
Enviado: martes, 14 de diciembre de 2021 16:03
Para: dev@activemq.apache.org 
Asunto: log4j (CVE-2021-44228) vulnerability and ActiveMQ 5.8.0

Hi
In a client I am working they use SAP PO and ActiveMQ 5.8.0 for some years.
Now we receive a note for the "log4j (CVE-2021-44228) vulnerability" and
checking the SAP O and the version of ActiveMQ 5.8.0 has this vulnerability.
For SAP PO SAP sent a fix today to solve the issue.
For ActiveMQ we think probably new version of ActiveMQ will solve it?
But also need to be compatible with SAP PO.

So I ask the community here to some advice.
If someone already encounter this issue and solved it and also some
evidence of the issue fix by ActiveMq (some doc or note) to justified the
upgrade.

Thanks!
Regards
Martin



Martin Piattini Velthuis, PMP - SAP CPI/PO/PI Consultant

PK – the Experience Engineering firm

M + 54 9 11 5644-8108

mpiatt...@pkglobal.com






--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.19.0

2021-10-14 Thread Timothy Bish 

On 10/11/21 10:13 PM, Justin Bertram wrote:

I would like to propose an Apache ActiveMQ Artemis 2.19.0 release.

We added these new features as part of 2.19.0:

- New ability to replay retained journal records via the management API.
- New environment/system property to set the "key" for masked passwords when
   using the default codec.
- Ability to disable message-load-balancing and still allow redistribution
via the new OFF_WITH_REDISTRIBUTION type.
- MQTT session state can now be cleaned up automatically to avoid excessive
   accumulation in situations where client's don't clean up their own
sessions.
- Distribute full Jakarta Messaging 3.0 client in the lib/client directory
   along with a new example of how to use it in
examples/features/standard/queue-jakarta.


The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12350519

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.19.0.html

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1238

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

The source tag:
https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=tree;h=28749a383b3c60faed3ec28f96905cf11f9d1bf0;hb=refs/tags/2.19.0

I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1


+1

* Validated signatures and checksums
* Verified license and notice files
* Check source for license headers
* Built from source and ran the AMQP tests


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.19.0

2021-10-13 Thread Timothy Bish 

On 10/13/21 7:06 AM, Gary Tully wrote:

the check sum seems wrong:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.0/apache-artemis-2.19.0-bin.tar.gz.sha512
can someone else verify?

I get: 
fbf14235851a3044d5c7732b1a21412c3b0fd5f312e814d2449c7e0533e9467718c48e577a80806a996593c626a8268aeee490beb93abef369ac9498130dc631

built from source, happy smoke-test of distro



The checksum seems ok but I could not find the key used to sign the 
release within the KEYS files located at:


https://dist.apache.org/repos/dist/release/activemq/KEYS



On Wed, 13 Oct 2021 at 08:26, Jean-Baptiste Onofre  wrote:

+1 (binding)

Regards
JB


Le 12 oct. 2021 à 04:13, Justin Bertram  a écrit :

I would like to propose an Apache ActiveMQ Artemis 2.19.0 release.

We added these new features as part of 2.19.0:

- New ability to replay retained journal records via the management API.
- New environment/system property to set the "key" for masked passwords when
  using the default codec.
- Ability to disable message-load-balancing and still allow redistribution
via the new OFF_WITH_REDISTRIBUTION type.
- MQTT session state can now be cleaned up automatically to avoid excessive
  accumulation in situations where client's don't clean up their own
sessions.
- Distribute full Jakarta Messaging 3.0 client in the lib/client directory
  along with a new example of how to use it in
examples/features/standard/queue-jakarta.


The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12350519

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.19.0.html

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.19.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1238

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

The source tag:
https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;a=tree;h=28749a383b3c60faed3ec28f96905cf11f9d1bf0;hb=refs/tags/2.19.0

I will update the website after the vote has passed.


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1



--
Tim Bish

Re: [VOTE] Release activemq-nms-amqp 2.0.0-rc1

2021-09-29 Thread Timothy Bish 

On 9/29/21 9:50 AM, Michael André Pearce wrote:

+1 from myself, run some basic tests and against artemis

Thanks for running the release, and to the contributors for this.

copying in PMC private list to get attention of the PMC.


On 21 Sep 2021, at 21:14, Havret  wrote:


Hi All,

I have put together a release of activemq-nms-amqp, please check it
and vote accordingly.

This release brings NMS 2.0 implementation.

The files can be grabbed from:
https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/2.0.0-rc1/

Regards,
Havret



-1

The following source files are missing Apache license headers:

/src/NMS.AMQP/Provider/Amqp/AmqpSubscriptionTracker.cs

./test/Apache-NMS-AMQP-Test/Message/Facade/AmqpNmsMessageFacadeTest.cs





--
Tim Bish

Re: [VOTE] Release activemq-nms-amqp 1.8.2-rc3

2021-08-30 Thread Timothy Bish 

On 8/30/21 3:47 PM, Havret wrote:

Can any of the PMC members move the artifacts from the dev area? :)



I've moved the artifacts to the release folder, I'll leave it to those 
managing the releases to update the site and remove older releases / 
release candidates as there are more than a few





On Sun, Aug 29, 2021 at 1:08 AM Robbie Gemmell 
wrote:


It's not something I can do, needs to be a PMC member.

On Fri, 27 Aug 2021 at 20:01, Havret  wrote:

Robbie, could you move the artifacts from the dev area, so I can finish

the

release? I asked Mike to do it, but he went on vacation.

On Fri, Aug 27, 2021 at 1:01 PM Robbie Gemmell 
There are still important outstanding steps remaining to complete the
release process. The release files were not officially published and
so are neither mirrored or archived yet, and the website wasnt updated
or a release announcement made. I see the package did make it to nuget
8 days ago though.


On Mon, 16 Aug 2021 at 10:49, Havret  wrote:

Results of the activemq-nms-amqp 1.8.2-rc3 release vote.

Vote passes with 4 votes.

The following votes were received:

Binding:
- Michael André Pearce
- Clebert Suconic
- Timothy Bish,
- Jeff Genender

There were no -1 or 0 votes cast.

Thank you to everyone who contributed and took the time to review the
release candidates and vote.

I'll move forward with getting the release out.

Regards
Havret

On Fri, Aug 6, 2021 at 7:48 AM Havret  wrote:


Hi,

I think I have all the votes I needed. Thanks for your votes and

your

feedback.

I will complete the release when I'm back from vacation. :)

Havret

On Thu, Aug 5, 2021 at 6:49 PM Jeff Genender 
wrote:

+1

Jeff



On Aug 4, 2021, at 2:48 PM, Michael André Pearce <

michael.andre.pea...@me.com.INVALID> wrote:

Just adding private list as some pmc have filters on there.

Sent from my iPad


On 4 Aug 2021, at 21:47, Michael André Pearce <

michael.andre.pea...@me.com.invalid> wrote:

+1 (binding) retested against both activemq classic and

artemis

latest releases.



Sent from my iPad


On 3 Aug 2021, at 15:56, Timothy Bish 

wrote:

On 7/31/21 5:07 PM, Havret wrote:
Hi,

This is the third attempt to release activemq-nms-amqp 1.8.2.

The missing headers were added, and SHA512 was generated

using

linux

sha512sum.

The files can be grabbed from:


https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/1.8.2-rc3/

Please check it and vote accordingly.

Regards,
Havret


+1

* Validated signatures and checksums
* Verified license and notice files are present and have

proper

dates

* Checked source for license headers using the Apache rat tool
* Built from source on Linux and ran the tests against an

Artemis

instance


--
Tim Bish





--
Tim Bish

Re: [VOTE] Release activemq-nms-amqp 1.8.2-rc2

2021-07-08 Thread Timothy Bish 

On 6/27/21 4:49 PM, Havret wrote:

Hi,

This is the second run for activemq-nms-amqp 1.8.2.

I've added the missing headers, updated the license files, and generated
SHA512 using powershell not gpg, so it should be more in line with what you
guys are used to.

The files can be grabbed from:
https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/1.8.2-rc2/

Please check it and vote accordingly.

Regards,
KP


+0

There still appear to be some missing license headers in test code such as:

./test/Apache-NMS-AMQP-Interop-Test/NmsSessionTest.cs

And I cannot get the sha files to validate using standard tooling 
without hand editing the files as they don't see to follow normal file 
formatting that's expected by the tooling as documented on the Apache 
release validation guidelines.


--
Tim Bish

Re: Which activeMQ (not Artemis) version will be JMS 2.0 or 3.0 ?

2021-05-19 Thread Timothy Bish 

On 5/19/21 6:17 AM, Christopher Shannon wrote:

Moving back to dev list again...

Yes we had talked about it before in terms of the client side but it wasn't
clear in this thread as your original answer on this thread was "ActiveMQ
5.17.0 will support JMS 2.0." with no caveats or clarification to mention
that it would not be full support. Seeing as how this was on the users list
that would be a bit misleading to users.

Also, I still don't really know what the point of "client side" support is
because you can use the JMS 2.0 jar with ActiveMQ as long as you don't call
the new methods. Looking at that code you linked it seems like the new
methods (like shared subscription creation) just delegate to the old JMS
1.1 methods such as in
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2/TomEESession.java

That behavior seems odd and confusing to me because if a user is calling
methods to make a shared subscription or shared durable but it wasn't
supported I think it would be much preferable to just throw an error or
something vs delegating back. It seems way worse to allow users to call
those methods with no errors as a user of the library would (no surprise)
be expecting it to provide a shared subscription and it doesn't with no
indidication. If someone is writing an application and their business logic
is asking for a shared subscription but we don't provide it then that is
very different semantics and would most likely break the application so I
think that's a pretty bad idea overall so I really don't see why we would
want to do that.


I'd have to agree here, the client shouldn't do the wrong thing just to 
pretend that it did something.  If it can't do it then it should fail so 
that people know what the limitations are, and also the limitations 
should be clearly and explicitly documented where people can find it.





Other people can chime in but I would be very likely to veto a code change
for client support that simply delegates 2.0 methods to 1.1 methods.

On Wed, May 19, 2021 at 12:09 AM Jean-Baptiste Onofre 
wrote:


By the way, correct me if I’m wrong, but it’s what we discussed last year:
start with the client the side, and then move forward for server side.

What we planned in 5.16.x will be in 5.17.x.

Regards
JB


Le 19 mai 2021 à 06:05, Jean-Baptiste Onofre  a écrit :

Hi,

The first step is at least the client support, similar to what have been

done on OpenEJB:



https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2
<
https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2


This allow TomEE to work with ActiveMQ using JMS 2.0.

So, the proposal is to have a two steps work:

1. Support JMS 2.0 client side, it will help in tomee, karaf, etc
2. Step by step implement server side support

IMHO, 1 would be good step forward already and it works fine for a while

in tomee. It will already allow us to update the spec.

Regards
JB


Le 18 mai 2021 à 21:09, Christopher Shannon <

christopher.l.shan...@gmail.com> a écrit :

What exactly are you proposing? Full support would be a tremendous

amount

of work. I started a thread on this already a while back here:


http://activemq.2283324.n4.nabble.com/DISCUSS-JMS-2-0-support-in-5-x-going-forward-td4757779.html

My issue here is the lack of clarity. I have no clue what you are

proposing

but it needs to be defined so we don't mislead users by claiming there

is

JMS 2.0 support when there isn't. I listed out possible paths forward in
that other thread.

On Tue, May 18, 2021 at 12:04 PM Jean-Baptiste Onofre 
wrote:


It’s something that we already discussed and I moved forward on the PR.

I propose to move forward on JMS 2.0 support.

If the community agree, and tests are fine, I don’t see any issue to
support it in 5.17.0 as best effort.

Anyway, I will propose the PR, and see when to include it.

Regards
JB


Le 18 mai 2021 à 17:36, Christopher Shannon <

christopher.l.shan...@gmail.com> a écrit :

Since when is JMS 2.0 supposed to be supported by 5.17.0?

None of the features are implemented on the server side for the new

API

calls. This was brought up in a dev discussion that there won't be JMS

2.0

support on the server side in this release.

On Tue, May 18, 2021 at 11:29 AM Jean-Baptiste Onofre <

j...@nanthrax.net>

wrote:


He’s not PMC but committer, so he can help anyway ;)

Regards
JB


Le 18 mai 2021 à 17:23, COURTAULT Francois <

francois.courta...@thalesgroup.com> a écrit :

Hello,

I don't think Romain is still the PMC for TomEE.

Best Regards.

-Original Message-
From: Jean-Baptiste Onofre 
Sent: mardi 18 mai 2021 17:19
To: us...@activemq.apache.org
Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0 or

3.0

?

Hi,

I’m sure I can ask help from Romain about TomEE releases ;)

Regards
JB


Le 18 mai 2021

Re: [VOTE] Apache ActiveMQ 5.16.2 release

2021-04-27 Thread Timothy Bish 

On 4/27/21 1:32 AM, Jean-Baptiste Onofre wrote:

Hi,

Gently reminder, we need a third binding vote.

Regards
JB


Le 21 avr. 2021 à 09:49, Jean-Baptiste Onofre  a écrit :

Hi everyone,

I submit Apache ActiveMQ 5.16.2 to your vote.

This release includes important fixes and updates on the 5.16.x series, 
especially;
- fix on the broker redelivery plugin
- fixes on WebConsole
- dependency updates
- and much more !

Please take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12349550
 


The Maven staging repository is:
https://repository.apache.org/content/repositories/orgapacheactivemq-1231/ 


The dist staging repository is:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.16.2/ 


Git tag:
activemq-5.16.2

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Checked for license and notice files in the archives
* Checked source using 'mvn apache-rat:check'
* Ran broker from binary archive and exercised the web console
* Built from source and ran a few of the modules test suites


--
Tim Bish

Re: Website update, announcement, CVE

2021-02-05 Thread Timothy Bish 
Did I miss the announcement going out?  Seems like it should have been done
by now but I don't see it, although website appears to but updated now.

On Fri, Jan 29, 2021 at 8:44 AM Jean-Baptiste Onofre 
wrote:

> Thanks Robbie,
>
> I was about to update website. Thanks for catching this !
>
> I will move forward on announcement.
>
> Regards
> JB
>
> > Le 29 janv. 2021 à 14:38, Robbie Gemmell  a
> écrit :
> >
> > I have just updated the website to change the download page to 5.16.1,
> > add the 5.16.1 release page (which notes the announced CVE Gary
> > already updated the site with), and fix the broken links for the
> > 5.16.0 page. The site should be updated before the prior release is
> > removed from mirrors, or it breaks the links.
> >
> > I leave any further tweaks and announcements needed to you.
> >
> > On Thu, 28 Jan 2021 at 05:00, Jean-Baptiste Onofre 
> wrote:
> >>
> >> Hi guys,
> >>
> >> Sorry, I’m late about website update, announcement and CVE publication
> for ActiveMQ 5.16.1.
> >>
> >> I will fix that asap (at least during the week end).
> >>
> >> Sorry about that,
> >> Regards
> >> JB
>
>

-- 
--
Tim Bish

Re: [PROPOSAL] Minimal JDK on ActiveMQ Artemis...

2021-01-14 Thread Timothy Bish 

On 1/12/21 11:35 AM, Clebert Suconic wrote:

I would like to propose requiring JDK 11 as a minimal requirement on
ActiveMQ Artemis on master, to be released as 2.17


+1




JDK 8 is about end of life, and that would open up better
possibilities on what we write in Artemis. JDK 8 is pretty old at this
point and we need to move on.



Anyone would object?



--
Clebert Suconic



--
Tim Bish

Re: ActiveMQ CPP with modern C++ standards

2020-12-17 Thread Timothy Bish 

On 12/17/20 4:01 PM, Matt Pavlovich wrote:

Aleksander-

I think a C-library and a C++ wrapper would have a lot of value, and open the 
ability to have some nice CLI tools for linux admins, container images, etc.

Something like ‘amq send | recv | browse | MY.QUEUE”

I agree, I think staying with standard libraries with fewest 3rd party 
dependencies is the way to go and provide the most utility.

The activemq-openwire-generator project might be a good place to look too. We 
could generate C structs out of there to get the protocol models generated and 
packaged for consumption by a C library and C++ wrapper library.

-Matt Pavlovich


On Dec 17, 2020, at 12:28 PM, Aleksander Miera  wrote:

@Arjun Ray:
I have been doing similar things, but I would pass custom deleters to 
unique_ptrs.
Not ideal maybe, but worked good enough in my case.
I can agree that authors copied Java style a bit overzealously, but we have 
what we have.
C API would be good, too, and IMHO it should not be that hard to provide it 
with the current codebase, though it might simply require a lot of typing.

Besides, regardless of its final shape I guess the project would benefit from 
simplifying it, e.g. by replacing platfrom-specific threads with std::thread.
If the "javaisms" are to be reworked into modern C++ is a matter of taste, but 
if it's possible to be done step by step I guess it should be considered, especially now 
when the C++'s standard library has become way richer.

@Mike thanks for information on how to contribute, hopefully it will become 
handy soon :)

Best regards,
Aleksander Miera


I think one's time would be better spent using and / or contributing to 
an AMQP v1.0 client library (which is an ISO standard protocol) vs 
inventing another Openwire client at this point.  AMQP offers a well 
defined specification that provides a much more robust credit model and 
message encoding flexibility etc that Openwire simply doesn't have. Plus 
it would work with any AMQP v1.0 compliant broker or message service 
unlike an Openwire client.


Apache Qpid already has such clients 
http://qpid.apache.org/proton/index.html and that is where I'd spend my 
time if I was to ever think of working in the C or C++ client space again.



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.16.0

2020-11-03 Thread Timothy Bish 

On 11/2/20 8:44 PM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.16.0 release.

This release is including these new features as part of 2.16.0:

[ARTEMIS-2901] - Support namespace for temporary queues
[ARTEMIS-2937] - AMQP Server Connectivity
[ARTEMIS-2947] - Implement SecurityManager that supports replication


[ARTEMIS-2937] AMQP Server Connectivity is actually a new module,
where you can use it to "bridge" messages, expand the broker
networking using AMQP and other products such as Qpid Dispatch,  and
also includes an option to mirror the broker asynchronously into
another broker and maybe another site. I would recommend reading the
documentation for more information:

https://github.com/apache/activemq-artemis/blob/master/docs/user-manual/en/amqp-broker-connections.md


The release notes is included here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348718



Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.16.0


The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1219

In case you want to give it a try with the maven repo on examples:
http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html

The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.16.0

I will update the website after the vote has passed.


[ ] + 1 approve the release as Apache ActiveMQ Artemis 2.16.0
[ ] + 0 no opinion
[ ] -1 disapprove (and reason why)


This vote will stay open for at least 72 hours. (End of day of
Thursday, Nov 5th 2020)


+1

* Verified signatures and checksums
* Verified license and notice files in archives
* Verified source license with apache-rat plugin
* Built from source archive and ran AMQP tests
* Ran broker from binary and tested with Qpid JMS example.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.15.0 release

2020-08-26 Thread Timothy Bish 

On 8/25/20 2:48 PM, Domenico Francesco Bruscino wrote:

I would like to propose an Apache ActiveMQ Artemis 2.15.0 release.

We added these new features as part of 2.15.0:

[ARTEMIS-2847] - socks5h support
[ARTEMIS-2855] - Define a new broker plugin to track XA transactions
[ARTEMIS-2857] - Expose ActivemqServer::isActivated through
ActiveMQServerControl

We had quite a few improvements on this release:

[ARTEMIS-2844] - Improve MQTT subscribe/unsubscribe topic performance
[ARTEMIS-2845] - ConcurrentAppendOnlyChunkedList cannot be queried while
resizing
[ARTEMIS-2863] - Support pausing dispatch during group rebalance
[ARTEMIS-2872] - Support FQQN syntax for security-settings
[ARTEMIS-2880] - Support FQQN syntax for JNDI lookup
[ARTEMIS-2882] - Better support for JMS topics + FQQN

And we also had some important fixes:

[ARTEMIS-2862] - Activation failure can result in zombie broker
[ARTEMIS-2868] - Split Brain on Replication could "damage" the Topology,
isolating the server
[ARTEMIS-2877] - Fix journal replication scalability

The release notes can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348568

Ths git commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.15.0

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.15.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1217

In case you want to give it a try with the maven repo on examples:
http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html

The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.15.0

I will update the website after the vote has passed.


[ ] +1 approve the release as Apache Artemis 2.15.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Here's my +1


+1

* Validated signatures and checksums
* Checked for presence of license and notice files
* Created new broker instance from binary tarball and ran some sanity checks
* Checked source licenses using Apache rat plugin
* Built from source and ran some of the tests including all AMQP test suite



--
Tim Bish

Re: Fwd: [IMPORTANT] - Migration to ci-builds.a.o

2020-07-30 Thread Timothy Bish 
I've attempted to migrate the old CI jobs that were actually running.  
The SNAPSHOT deploy jobs seemed to have worked and the other test run 
jobs are running with failing tests as before.  I'd recommend folks 
check the projects they are concerned about and see if other jobs are 
needed and / or check the test results of the current jobs to try and 
stabilize the builds.


On 7/24/20 8:32 AM, Robbie Gemmell wrote:

I haven't seen this mail discussed, or any jobs migrated onto the new
Jenkins setup, so I thought I'd forward it in case folks aren't
actually aware.

Existing Jenkins jobs need to be migrated to the new servers or the
job will effectively be lost on August 15th. You need to ask for an
ActiveMQ job folder to be created (via Jira, or there is a specific
mail thread for it now) on the new server first so you can add jobs in
it.

I added a view to the old Jenkins to group any existing "ActiveMQ.*"
named jobs, which folks might want to migrate (I think a view like
this used to exist, but I couldn't see it so I made one):
https://builds.apache.org/view/A-D/view/ActiveMQ/

More threads and details on builds@a.o
(https://lists.apache.org/list.html?bui...@apache.org)

Robbie

-- Forwarded message -
From: Gavin McDonald 
Date: Thu, 16 Jul 2020 at 17:33
Subject: [IMPORTANT] - Migration to ci-builds.a.o
To: builds 


Hi All,

This NOTICE is for everyone on builds.apache.org. We are migrating to a new
Cloudbees based Client Master called https://ci-builds.apache.org. The
migrations of all jobs needs to be done before the switch off date of 15th
August 2020, so you have a maximum of 4 weeks.

There is no tool or automated way of migrating your jobs, the
differences in the platforms, the plugins and the setup makes it impossible
to do in a safe way. So, you all need to start creating new jobs on
ci-infra.a.o and then , when you are happy, turn off your old builds on
builds.a.o.

There are currently 4 agents over there ready to take jobs, plus a floating
agent which is shared amongst many masters (more to come). I will migrate
away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
will keep an eye of load across both and adjust accordingly.

If needed, create a ticket on INFRA jira for any issues that crop up, or
email here on builds@a.o. there may be one or two plugins we need to
install/tweak etc.

We will be not using 'Views' at the top level, but rather we will take
advantage of 'Folders Plus' - each project will get its own Folder and have
authorisation access to create/edit jobs etc within that folder. I will
create these folders as you ask for them to start with. This setup allows
for credentials isolation amongst other benefits, including but not limited
to exclusive agents (Controlled Agents) for your own use , should you have
any project targeted donations of agents.

As with other aspects of the ASF, projects can choose to just enable all
committers access to their folder, just ask.

We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
be setting up any forwarding rules or anything like that.

So, please, get started *now *on this so you can be sure we are all
completed before the final cutoff date of 15th August 2020.

Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
tickets.

Hadoop and related projects have their own migration path to follow, same
cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
very well in their new homes.

Lets get going ...

--

*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team



--
Tim Bish

Re: Fwd: [IMPORTANT] - Migration to ci-builds.a.o

2020-07-29 Thread Timothy Bish 
I requested a folder be created for ActiveMQ and they've finally gotten 
round to it

https://ci-builds.apache.org/job/ActiveMQ/

Can now start to migrate jobs to the new CI

On 7/24/20 8:32 AM, Robbie Gemmell wrote:

I haven't seen this mail discussed, or any jobs migrated onto the new
Jenkins setup, so I thought I'd forward it in case folks aren't
actually aware.

Existing Jenkins jobs need to be migrated to the new servers or the
job will effectively be lost on August 15th. You need to ask for an
ActiveMQ job folder to be created (via Jira, or there is a specific
mail thread for it now) on the new server first so you can add jobs in
it.

I added a view to the old Jenkins to group any existing "ActiveMQ.*"
named jobs, which folks might want to migrate (I think a view like
this used to exist, but I couldn't see it so I made one):
https://builds.apache.org/view/A-D/view/ActiveMQ/

More threads and details on builds@a.o
(https://lists.apache.org/list.html?bui...@apache.org)

Robbie

-- Forwarded message -
From: Gavin McDonald 
Date: Thu, 16 Jul 2020 at 17:33
Subject: [IMPORTANT] - Migration to ci-builds.a.o
To: builds 


Hi All,

This NOTICE is for everyone on builds.apache.org. We are migrating to a new
Cloudbees based Client Master called https://ci-builds.apache.org. The
migrations of all jobs needs to be done before the switch off date of 15th
August 2020, so you have a maximum of 4 weeks.

There is no tool or automated way of migrating your jobs, the
differences in the platforms, the plugins and the setup makes it impossible
to do in a safe way. So, you all need to start creating new jobs on
ci-infra.a.o and then , when you are happy, turn off your old builds on
builds.a.o.

There are currently 4 agents over there ready to take jobs, plus a floating
agent which is shared amongst many masters (more to come). I will migrate
away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
will keep an eye of load across both and adjust accordingly.

If needed, create a ticket on INFRA jira for any issues that crop up, or
email here on builds@a.o. there may be one or two plugins we need to
install/tweak etc.

We will be not using 'Views' at the top level, but rather we will take
advantage of 'Folders Plus' - each project will get its own Folder and have
authorisation access to create/edit jobs etc within that folder. I will
create these folders as you ask for them to start with. This setup allows
for credentials isolation amongst other benefits, including but not limited
to exclusive agents (Controlled Agents) for your own use , should you have
any project targeted donations of agents.

As with other aspects of the ASF, projects can choose to just enable all
committers access to their folder, just ask.

We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
be setting up any forwarding rules or anything like that.

So, please, get started *now *on this so you can be sure we are all
completed before the final cutoff date of 15th August 2020.

Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
tickets.

Hadoop and related projects have their own migration path to follow, same
cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
very well in their new homes.

Lets get going ...

--

*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team



--
Tim Bish

Re: [DISCUSS] automated website build, inc trial setup

2020-07-28 Thread Timothy Bish 

On 7/22/20 2:36 PM, Robbie Gemmell wrote:

Following on from an earlier thread around Jekyll versions and build
issues etc, I have just gone through the hoops with infra and put an
automated website build in place for a trial and discussion. Folks can
now give it a try out and we could decide if it or a variant is
desirable to use going forward.

Any source changes committed to the jekyll-test-master branch of the
website repo will currently be automatically built, committed to the
asf-staging branch, and staged to https://activemq.staged.apache.org/.
The process can take a few minutes as the site is so large.

With this setup you would e.g check all is well in staging, and then
rebase a further live branch (e.g asf-site) in the repo with the
staged commits from asf-staging and push there. Alternatively it could
just build straight to the live branch without any staging (I used the
staging area as it is a test, and it was already sitting there from
last year).

E.g I made this change on jekyll-test-master:
https://github.com/apache/activemq-website/commit/c958e5042d7a4c095db351cfb3cf388c6711037b

which was built automatically in:
https://ci2.apache.org/#/builders/7/builds/145

then output committed back to the asf-staging branch in:
https://github.com/apache/activemq-website/commit/103dc43c8f77a101fca7ad82f225da8efc7c5945

and is now visible in the text on the front at
https://activemq.staged.apache.org/

Thoughts?

Robbie


+1

LGTM

--
Tim Bish

Re: [DISCUSS] Draft proposal for terminology change

2020-07-27 Thread Timothy Bish 

On 7/25/20 2:24 PM, Matt Pavlovich wrote:

Kicking off draft proposal conversation, we can then convert this to a ticket. 
I’ve collected ideas from the recent dev mailing list convo. I’m sure I’ve 
missed some key points and am not married to anything here. Please chime in!

Description: Support migration of terms such as ‘master’ and ’slave’.

Proposed steps:
1. Deprecate terms such as ‘master’ and ’slave
2. log.warn any configuration change notifications
3. Provide compatibility under the covers for deprecated terms
4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
5. Notify users in an announcement and provide a conversion HOWTO
6. Other?

New terms:
a. For shared storage: ‘active’ and ’standby’
b. For replication: ‘primary’ and ‘replica'

For example:
‘master’ -> ‘active’
’slave’ -> ’standby'

Thanks,
Matt Pavlovich


+1


--
Tim Bish

Re: [VOTE] Apache ActiveMQ CLI Tools 0.2.0

2020-07-21 Thread Timothy Bish 

On 7/21/20 1:03 PM, Gary Tully wrote:

Hi Everyone,
I have a candidate for vote.
This has support for migrating virtual topic consumer queues to durable
subscription queues as part of kahadb export.

doc:  https://github.com/apache/activemq-cli-tools

The list of resolved issues is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340567==12320821


You can get binary distributions here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
activemq/activemq-cli-tools/0.2.0/

Source archives are here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1215/org/apache/
activemq/activemq-cli-tools-parent/0.2.0/

Maven repository is at:
https://repository.apache.org/content/repositories/orgapacheactivemq-1215


Source tag:
https://git-wip-us.apache.org/repos/asf?p=activemq-cli-tools.git;a=tag;h=refs/tags/0.2.0

Please vote to approve this release.  The vote will remain open for 72
hours.

[ ] +1 Release the binary as Apache ActiveMQ CLI Tools 0.2.0
[ ] -1 (provide specific comments)

Here's my +1


I don't see any artifacts uploaded to the staging site for this release so I 
cannot review them since
I don't know what the artifacts are that are actually going to get moved to 
dist release in the end.

https://dist.apache.org/repos/dist/dev/

--
Tim Bish

Re: Replace racially charged terms throughout source code, comments and documentation

2020-07-15 Thread Timothy Bish 

On 7/15/20 3:48 PM, Christopher Shannon wrote:

Actually this may be easier than I thought. I forgot that OpenWire doesn’t
include property names so we might be able to get away with just renaming
things and everything would work fine and be compatible as long as
properties are in the same order. It needs to be looked at more to verify
of course.


Agreed, took a quick look and from the wire level perspective the older 
clients wouldn't care what the broker libraries called those fields as 
they are decoded in relative order by the broker marshaling code.  You'd 
need to change the set calls in both the versions in activemq-client and 
in activemq-openwire-legacy but that should still only constitute a 
broker level change (and new client release that accompanies it).   
Possible there's some case where it matters but it isn't immediately 
apparent.





On Wed, Jul 15, 2020 at 3:18 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:


Gary, that makes sense to me as I think making sure everything is
backwards compatible for existing users is important. (not just for
openwire but all config, etc) There would need to be some work done in the
broker to know which properties to use based on the negotiated openwire
version and be able to fall back to old variables and config if needed.

On Tue, Jul 14, 2020 at 7:51 AM Gary Tully  wrote:


I think for openwire, rename and a change in openwire version is the way
to go.
keeping the old terms around for backward compatibility is both
sensible and necessary.

On Tue, 14 Jul 2020 at 11:42, Christopher Shannon
 wrote:

I agree that it is time to make the change. Justin made a good point in
that we should make sure to pick the best and most descriptive names
possible for the use case. Whether that is follower/leader,
primary/secondary, primary/replica, live/backup, etc. I think

live/backup

certainly makes a lot of sense for Artemis. For 5.x I think it also

makes

sense but primary/secondary is fine too.

My main concern here is how do we handle the technical issues with
compatibility? For example, do we just deprecate the old configuration

and

terminology to not break users or do we rip it out entirely initially

which

would be a breaking change for users that needs to be well communicated?
For Artemis, maybe we deprecated in 2.x and in 3.x.

Another thing is some things will be easy to change and others not so
much.  For something like the LevelDB store that uses the terminology

this

is easy as we can just remove it entirely as we plan to remove it in

5.17

anyways. However, one thing that does seem like a challenge to fix is
OpenWire. For example the BrokerInfo command actually uses the terms
slaveBroker and masterBroker. Renaming these would now break

compatibility

with brokers running older versions of 5.x.  I think the only way it

would

work is to keep the terms around for the older versions of OpenWire and
then generate a new version that has them renamed which I'm not sure if
that is or isn't acceptable as the software would still be distributed

with

those older terms laying around.

On Mon, Jul 13, 2020 at 11:57 PM Xeno Amess 

wrote:

They did?
OK, then I have no more doubts.

Justin Bertram  于2020年7月14日周二 上午11:42写道：


For what it's worth, GitHub is changing the default branch name so

there's

no argument to be had with them as you suggest. See here [1] for

example.


Justin

[1] https://www.bbc.com/news/technology-53050955

On Mon, Jul 13, 2020, 10:24 PM Xeno Amess 

wrote:

Hi.
If you really think "master" is something you cannot accept, then

you

might

argue with github first.
after all their default git branch name is "master", and github

have

far

more user than ActiveMQ.

Bruce Snyder  于2020年7月14日周二 上午11:03写道：


Someone mentioned use of the terms 'primary' and 'backup' in the

private

list and I liked that suggestion. I'm not wed to any terms

necessarily,

so

if Artemis is already using the terms 'live' and 'backup', I'm

ok

with

that

in ActiveMQ.

Bruce

On Mon, Jul 13, 2020 at 8:42 PM Justin Bertram <

jbert...@apache.org>

wrote:


Thanks for kicking this off, Bruce.

Among other things the Jira [1] says:


'master' and 'slave' should be replaced with the terms

'primary,'

'secondary,' 'tertiary,' etc.

I would offer "live" and "backup" as suitable replacements for

"master"

and

"slave" respectively. The Artemis code and documentation

already

use

"live"

and "backup" in many places although some instances of

"master" and

"slave"

do exist. Aside from the fact that they're already in use I

like

the

fact

that they're relatively short and they clearly capture the

underlying

functional semantic. In my opinion the terms "primary,"

"secondary,"

etc.

are actually a bit vague and they're certainly quite a bit

longer

which

isn't a huge deal but it adds up when writing tests,

documentation,

etc.


Justin

[1] https://issues.apache.org/jira/browse/AMQ-7514

On Mon, Jul 13, 2020 at 3:04 PM Bruce

Re: [VOTE] Apache ActiveMQ Artemis 2.14.0

2020-07-10 Thread Timothy Bish 

On 7/10/20 9:26 AM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.14.0 release.

We only added one feature as part of this release:

[ARTEMIS-2770] - Update diverts using the management API

And we have quite a few improvements on this release:

[ARTEMIS-2109] - enable building Artemis with JDK 11+
[ARTEMIS-2771] - Support JVM GC & thread metrics
[ARTEMIS-2776] - Dockerfile improvements to startup arguments
[ARTEMIS-2786] - Timestamp in console is incorrect
[ARTEMIS-2787] - Allow a queue to be disabled, so that messages are not
routed to it.
[ARTEMIS-2797] - Reset queue properties by unsetting them in broker.xml
[ARTEMIS-2807] - Avoid notifications on critical IO error
[ARTEMIS-2820] - Undeploy diverts by removing them from broker.xml
[ARTEMIS-2827] - Add addressMemoryUsagePercentage as metric
[ARTEMIS-2828] - Add addressSize as metric



The whole release notes is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348290==12315920=Create_token=A5KQ-2QAV-T4JA-FDED_4d142d7a703c84c576af5fabc058fb51bb1473f2_lin


Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.14.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1214

In case you want to give it a try with the maven repo on examples:
http://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


I will update the website after the vote has passed.


[ ] +1 approve the release as Apache Artemis 2.4.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

+1

* Verified signatures and checksums
* Checked for license and notice files in archives
* Verified source license headers with Apache Rat
* Ran binary broker instance and tested with Qpid JMS examples and 
exercised the web console

* Built from source and ran some of the tests in the integration test suite.

Should note that I noticed there seems to be an issue in the maven build 
configuration that is preventing specification of test filters at the 
command line like the following: "mvn test -Ptests 
-Dtest=org.apache.activemq.artemis.tests.integration.amqp.*".  It isn't 
clear yet what is breaking but the filters don't seem to be applied 
correctly and no tests are run even though there are tests that match 
this, and this did work in previous releases.


--
Tim Bish

Re: [VOTE] ActiveMQ Artemis Native 1.0.2

2020-06-17 Thread Timothy Bish 

On 6/15/20 11:19 AM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis Native 1.0.2 release.


Artemis native is a dependency for Artemis responsible for the journal
type libaio. It's basically a JNI wrapper submitting writes to the
kernel on Linux.


I have already tested the testsuite with this release and it worked fine.


As part of this release, I'm addressing:

https://issues.apache.org/jira/browse/ARTEMIS-2800 Work around kernel issue


I'm trapping the issue before it happened on the kernel. So in case
you are running artemis-native on a kernel with the offending bug, it
would work around the issue and the broker would not crash.

So far this has only been seen on RHEL 7.8 as further releases on
kernel upstream already contain a fix. But I want to prevent it from
ever happening again.


The release notes is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346447

The repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1211/

The tag is here:
https://gitbox.apache.org/repos/asf/activemq-artemis-native.git;a=tag;h=refs/tags/1.0.2

Steps to use the staged maven repo:
http://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

I update the website after the vote has passed.

Notice that we will only provide sources for this release, and the
maven repository as the source for binaries.

[ ] +1 approve the release as Apache Artemis 2.4.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1



+1

* Validated signatures and checksums
* Verified source archives both have license and notice files
* Verified license headers on source using 'mvn apache-rat:check'
* Verified scripts all have license headers
* Ran some of the build scripts without issue


--
Tim Bish

Re: [VOTE] ActiveMQ Artemis Native 1.0.2

2020-06-16 Thread Timothy Bish 

On 6/15/20 11:19 AM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis Native 1.0.2 release.


Artemis native is a dependency for Artemis responsible for the journal
type libaio. It's basically a JNI wrapper submitting writes to the
kernel on Linux.


I have already tested the testsuite with this release and it worked fine.


As part of this release, I'm addressing:

https://issues.apache.org/jira/browse/ARTEMIS-2800 Work around kernel issue


I'm trapping the issue before it happened on the kernel. So in case
you are running artemis-native on a kernel with the offending bug, it
would work around the issue and the broker would not crash.

So far this has only been seen on RHEL 7.8 as further releases on
kernel upstream already contain a fix. But I want to prevent it from
ever happening again.


The release notes is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346447

The repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1211/

The tag is here:
https://gitbox.apache.org/repos/asf/activemq-artemis-native.git;a=tag;h=refs/tags/1.0.2

Steps to use the staged maven repo:
http://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html

I update the website after the vote has passed.

Notice that we will only provide sources for this release, and the
maven repository as the source for binaries.

[ ] +1 approve the release as Apache Artemis 2.4.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1



I don't see any artifacts uploaded to the staging site for this release 
so I cannot review them


https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/



--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.15.13 release

2020-05-27 Thread Timothy Bish 

On 5/25/20 7:42 AM, Jean-Baptiste Onofre wrote:

Hi everyone,

I'm submitting ActiveMQ 5.15.13 release to your vote.

This release includes several bug fixes and improvements.

Please take a look on the Release Notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12347002
 


The Maven staging repository is:
https://repository.apache.org/content/repositories/orgapacheactivemq-1210/ 


The dist staging repository is:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.13/ 


Git tag:
activemq-5.15.13

Website PR:
https://github.com/apache/activemq-website/pull/31 


Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB

+1

* Validated signatures and checksums
* Checked for license and notice files in archives
* Checked source using Apache RAT plugin
* Built from source and ran a selection of the unit tests
* Ran broker instance from binary archive and tested using Qpid JMS 
example and exercised the web console




--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.13.0

2020-05-18 Thread Timothy Bish 



+1

* Validated signatures and checksums
* Verified license and notice files in the archives
* Checked source for license headers using Apache Rat plugin
* Built from source and ran the AMQP tests
* Ran the Qpid JMS example against the binary broker archive instance.
* Ran some AMQP performance tests to verify no more credit handling issues

On 5/18/20 12:26 PM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.13.0 release.


This release will include these features:

[ARTEMIS-2666] - Add management for duplicate ID cache
[ARTEMIS-2726] - Implement min/max expiry-delay
[ARTEMIS-2738] - Implement per-acceptor security domains
[ARTEMIS-2739] - Artemis health check tool
[ARTEMIS-2758] - Support disabling metrics per address
[ARTEMIS-2761] - Supporting QUOTED-IDS on expressions to align with qpid-jms

There was a significant improvement in AMQP. With a recent fix in Flow
control combined with previous changes in scheduling, Performance in
AMQP is significant fast to any previous version. I personally spent
time on profiling AMQP and the server does not show much fat to cut on
processing, which means.. that's really fast.

AMQP is a serious contender to even Artemis Core protocol.

The release notes is here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12348088

The git commit report is here:
http://activemq.apache.org/components/artemis/download/commit-report-2.13.0


Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.13.0/

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1209

In case you want to give it a try with the maven repo on examples:
http://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.13.0


I will update the website after the vote has passed.



[ ] +1 approve the release as Apache Artemis 2.4.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1



--
Tim Bish

Re: [Artemis] AMQP Acknowledge confirmation

2020-05-11 Thread Timothy Bish 

On 5/11/20 2:42 PM, Krzysztof wrote:

If the broker doesn't support that I could set pie in the sky on my link
and that would change nothing. :)


Given that would result in an invalid AMQP encoding for the link attach 
frame I'm pretty sure it would change something.





On Mon, May 11, 2020 at 8:16 PM Timothy Bish  wrote:


On 5/11/20 1:33 PM, Krzysztof wrote:

@Robbie
I'm not sure what you mean by exactly-once. If you mentioned it in terms

of

delivery semantics, then nope, I'm not sure that would be enough.
Exactly-once is just a pipe dream, isn't it? Even if broker sends this

ack

back, your client could die in the meantime.

I would merely like to be sure that the broker has seen and processed the
ack, that's it. The same way as it is done for message transfer. I'm
sending the message to the broker and the broker replies: I've got it.

@Timothy So I've tried to do it both ways. With settled=true and
settled=false. And I got no reply. But as Robbie suggests, maybe the

broker

just doesn't support this.

The broker doesn't support this and probably shouldn't unless you intend
to implement exactly once which as you say is not something likely to
ever actually work.  Your client likely is attaching with receiver
settlement mode of 'first' so even if you send a disposition which
carries an outcome without settling the broker is not required to
respond to you as you've indicated that you will settle first.



On Mon, May 11, 2020 at 4:19 PM Robbie Gemmell 
Tim's reference will cover this, but essentially what you are
describing would only typically happen as part of doing exactly-once
if the client and broker had negotiated a receiver-settles-second link
rcv-settle-mode. The broker doesnt support that mode to my knowledge,
and so will indicate it is only doing receiver-settles-first. Even if
it did support it, most clients that might let you negotiate such a
rcv-settle-mode probably still cant do exactly-once as that also
requires fixed link names with unsettled state link resumption
negotiation (and some form of client side persistence to do that
properly) which I'm not aware of a client supporting.

On Sun, 10 May 2020 at 17:44, Krzysztof  wrote:

So as I said, I'm sending Disposition frame "amqp:disposition:list"
with Accepted state "amqp:accepted:list". My assumption is that the

broker

should reply with the same, once the message is
successfully acknowledged (aka removed from queue). Currently,

AmqpNetLite

sends dispositions is a fire-and-forget manner (sth like qpid-jms does
with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
client cannot be sure that its disposition was processed.

For more context -->
https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722

On Sun, May 10, 2020 at 5:46 PM Timothy Bish 

wrote:

On 5/10/20 11:34 AM, Krzysztof wrote:

Hi,

I am working on the implementation of AcceptAsync for AmqpNetLite

but I

wasn't able to make Artemis issue any response to disposition frame

with

the accepted state. Is this actually a supported feature? Maybe I am
missing sth.

Best,
Krzysztof


What frames are you sending and what frames are you wanting to get

back,

it isn't entirely clear from this little context, a bit more

specificity

might help here.

--
Tim Bish



--
Tim Bish




--
Tim Bish

Re: [Artemis] AMQP Acknowledge confirmation

2020-05-11 Thread Timothy Bish 

On 5/11/20 1:33 PM, Krzysztof wrote:

@Robbie
I'm not sure what you mean by exactly-once. If you mentioned it in terms of
delivery semantics, then nope, I'm not sure that would be enough.
Exactly-once is just a pipe dream, isn't it? Even if broker sends this ack
back, your client could die in the meantime.

I would merely like to be sure that the broker has seen and processed the
ack, that's it. The same way as it is done for message transfer. I'm
sending the message to the broker and the broker replies: I've got it.

@Timothy So I've tried to do it both ways. With settled=true and
settled=false. And I got no reply. But as Robbie suggests, maybe the broker
just doesn't support this.


The broker doesn't support this and probably shouldn't unless you intend 
to implement exactly once which as you say is not something likely to 
ever actually work.  Your client likely is attaching with receiver 
settlement mode of 'first' so even if you send a disposition which 
carries an outcome without settling the broker is not required to 
respond to you as you've indicated that you will settle first.





On Mon, May 11, 2020 at 4:19 PM Robbie Gemmell 
wrote:


Tim's reference will cover this, but essentially what you are
describing would only typically happen as part of doing exactly-once
if the client and broker had negotiated a receiver-settles-second link
rcv-settle-mode. The broker doesnt support that mode to my knowledge,
and so will indicate it is only doing receiver-settles-first. Even if
it did support it, most clients that might let you negotiate such a
rcv-settle-mode probably still cant do exactly-once as that also
requires fixed link names with unsettled state link resumption
negotiation (and some form of client side persistence to do that
properly) which I'm not aware of a client supporting.

On Sun, 10 May 2020 at 17:44, Krzysztof  wrote:

So as I said, I'm sending Disposition frame "amqp:disposition:list"
with Accepted state "amqp:accepted:list". My assumption is that the

broker

should reply with the same, once the message is
successfully acknowledged (aka removed from queue). Currently,

AmqpNetLite

sends dispositions is a fire-and-forget manner (sth like qpid-jms does
with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
client cannot be sure that its disposition was processed.

For more context -->
https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722

On Sun, May 10, 2020 at 5:46 PM Timothy Bish 

wrote:

On 5/10/20 11:34 AM, Krzysztof wrote:

Hi,

I am working on the implementation of AcceptAsync for AmqpNetLite

but I

wasn't able to make Artemis issue any response to disposition frame

with

the accepted state. Is this actually a supported feature? Maybe I am
missing sth.

Best,
Krzysztof


What frames are you sending and what frames are you wanting to get

back,

it isn't entirely clear from this little context, a bit more

specificity

might help here.

--
Tim Bish




--
Tim Bish

Re: [Artemis] AMQP Acknowledge confirmation

2020-05-10 Thread Timothy Bish 

On 5/10/20 12:44 PM, Krzysztof wrote:

So as I said, I'm sending Disposition frame "amqp:disposition:list"
with Accepted state "amqp:accepted:list". My assumption is that the broker
should reply with the same, once the message is
successfully acknowledged (aka removed from queue). Currently, AmqpNetLite
sends dispositions is a fire-and-forget manner (sth like qpid-jms does
with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
client cannot be sure that its disposition was processed.


Since the disposition frame carries more than just the delivery state I 
will have to guess based on the mention of Qpid JMS that you are doing 
something similar and your receiver attached with the Receiver 
Settlement Mode of first thereby indicating that your dispositions are 
also sent with the settled flag set to true along with the indicated 
accepted state.  If that is the case than the broker would not send you 
any response as you've settled thereby indicating that you have 
forgotten about delivery and removed it from the unsettled tracking on 
the receiver end.


You can refer to section 2.6.12 of the specification for a more in depth 
discussion of how the exchange of dispositions might occur based on the 
type of delivery semantics.





For more context -->
https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722

On Sun, May 10, 2020 at 5:46 PM Timothy Bish  wrote:


On 5/10/20 11:34 AM, Krzysztof wrote:

Hi,

I am working on the implementation of AcceptAsync for AmqpNetLite but I
wasn't able to make Artemis issue any response to disposition frame with
the accepted state. Is this actually a supported feature? Maybe I am
missing sth.

Best,
Krzysztof


What frames are you sending and what frames are you wanting to get back,
it isn't entirely clear from this little context, a bit more specificity
might help here.

--
Tim Bish




--
Tim Bish

Re: [Artemis] AMQP Acknowledge confirmation

2020-05-10 Thread Timothy Bish 

On 5/10/20 11:34 AM, Krzysztof wrote:

Hi,

I am working on the implementation of AcceptAsync for AmqpNetLite but I
wasn't able to make Artemis issue any response to disposition frame with
the accepted state. Is this actually a supported feature? Maybe I am
missing sth.

Best,
Krzysztof

What frames are you sending and what frames are you wanting to get back, 
it isn't entirely clear from this little context, a bit more specificity 
might help here.


--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.12.0 RC2

2020-04-22 Thread Timothy Bish 



+1

* Checked archives for license and notice files
* Verified signatures and checksums
* Checked source license headers 'mvn apache-rat:check -P release'
* Ran the broker from the binary release archive and checked admin 
console and ran Qpid JMS examples against it

* Ran the AMQP integration tests on multiple machines several times.

On 4/21/20 5:59 PM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.12.0 release.

This is a second try after I cancelled the release after a possible blocker.

We added the following features as part of 2.12.0:

[ARTEMIS-1194] - SOCKS proxy support
[ARTEMIS-1975] - Real LargeMessage support for AMQP
[ARTEMIS-2587] - ActiveMQ5-like dead letter strategy
[ARTEMIS-2613] - Support DivertBindings for Federated Addresses
[ARTEMIS-2624] - Auto-create expiry resources
[ARTEMIS-2692] - Provide Improved API for Queue Creation

and it also include the fix for the previous blocker I identified:

[ARTEMIS-2728] Fixing Deadlock with LargeServerMessage



Also, I want to highlight the Large Message support for AMQP, which is
a major enhancement that required some refactoring on the broker to
implement this feature.

We also added a new API for queue creation, simplifying operations on
embedded broker or Core Client.

This is also among many bug fixes. The complete release report can be
found here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346675

A detailed commit report:
http://activemq.apache.org/artemis/commit-report-2.12.0.html

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.12.0

The staged Maven Repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1208

Instructions to how to validate the maven repository if you want to
give it a try:
http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html

The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.12.0

I will update the website after the vote has passed

[ ] +1 approve the release as Apache Artemis 2.12.0
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)



--
Tim Bish

Re: [HEADS UP] ActiveMQ Artemis 2.12 release on April 13th and May 4th

2020-04-09 Thread Timothy Bish 

On 4/9/20 4:25 PM, Clebert Suconic wrote:

I just did
mvn install -Prelease

and it completed fine, without any issues. Even running the basic tests.


if you know anything wrong, please let me know before monday? as I
tried here and everything seems ok. I think Domenico also did build on
his environment and so far everything is good.


I've run through the AMQP tests quite a few times and nothing failed on 
either of my machines.





It could be something environmental in your system. I just tried on a
brand new Windows 10 machine I have at home, and everything seems ok.

On Wed, Apr 8, 2020 at 1:37 PM Clebert Suconic
 wrote:

@Michael: Is the problem running the testsuite on windows?

On Wed, Apr 8, 2020 at 12:28 PM brusdev  wrote:

Hi Micheal,

I have downloaded java-1.8.0-openjdk-1.8.0.212-3 and now my environment is
like yours:
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T20:33:14+02:00)
Maven home: C:\Program Files\apache-maven-3.5.4\bin\..
Java version: 1.8.0_212-3-redhat, vendor: Oracle Corporation, runtime:
c:\Program Files\RedHat\java-1.8.0-openjdk-1.8.0.212-3\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"


I have successfully built on the root path `activemq-artemis` using `mvn
-Pdev clean install -DskipTests=true` after that I have successfully built
on the path `activemq-artemis\artemis-protocols\artemis-mqtt-protocol` using
`mvn install`.

Analyzing your log I found a `java.lang.ClassNotFoundException:
EmbeddedJMSResource`.

It looks strange to me. I think you could have a dirty maven cache.
I used a vanilla Windows 10 and I could get any building errors.
I can share my machine if you need to do some tests.

[INFO] Scanning for projects...
[INFO]
[INFO] -< org.apache.activemq:artemis-mqtt-protocol

--

[INFO] Building ActiveMQ Artemis MQTT Protocol 2.12.0-SNAPSHOT
[INFO] ---[ bundle
]---
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @
artemis-mqtt-protocol ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-java) @
artemis-mqtt-protocol ---
[INFO]
[INFO] --- maven-dependency-plugin:3.1.1:unpack (copy) @
artemis-mqtt-protocol ---
[INFO] Configured Artifact:
org.apache.activemq:activemq-artemis-native:1.0.1:jar
[INFO] activemq-artemis-native-1.0.1.jar already unpacked.
[INFO]
[INFO] --- maven-remote-resources-plugin:1.5:process
(process-resource-bundles) @ artemis-mqtt-protocol ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
artemis-mqtt-protocol ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
artemis-mqtt-protocol ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-checkstyle-plugin:3.0.0:check (default) @
artemis-mqtt-protocol ---
[INFO]
[INFO] --- apache-rat-plugin:0.12:check (default) @ artemis-mqtt-protocol
---
[INFO] RAT will not execute since it is configured to be skipped via system
property 'rat.skip'.
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources)
@ artemis-mqtt-protocol ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
artemis-mqtt-protocol ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @
artemis-mqtt-protocol ---
[INFO] Surefire report directory:
C:\Users\bruscinodf\Workspace\brusdev\activemq-artemis\artemis-protocols\artemis-mqtt-protocol\target\surefire-reports
[WARNING] The system property basedir is configured twice! The property
appears in  and any of ,
 or user property.

---
  T E S T S
---
Running
org.apache.activemq.artemis.core.protocol.mqtt.MQTTRetainMessageManagerTest
[main] 18:15:31,909 WARN  [org.apache.activemq.artemis.core.server]
AMQ222018: AIO was not located on this platform, it will fall back to using
pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO
journal
[main] 18:15:31,928 WARN  [org.apache.activemq.artemis.core.server]
AMQ69: Please use a fixed value for "journal-pool-files". Default
changed per https://issues.apache.org/jira/browse/ARTEMIS-1628
[main] 18:15:34,505 INFO  [org.apache.activemq.artemis.core.server]
AMQ221000: live Message Broker is starting with configuration Broker
Configuration
(clustered=false,journalDirectory=data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/largemessages,pagingDirectory=data/paging)
[main] 18:15:34,526 INFO  [org.apache.activemq.artemis.core.server]
AMQ221057: Global Max Size is being

Re: [HEADS UP] ActiveMQ Artemis 2.12 release on April 13th and May 4th

2020-04-07 Thread Timothy Bish 
I'd recommend looking into the failures documented in this issue as they 
seem to indicate regressions in the AMQP protocol handler stack as 
compared to the previous release which doesn't seem to reproduce these 
from testing myself and Robbie have done.


https://issues.apache.org/jira/browse/ARTEMIS-2659

I'd be inclined to -1 any release that still expresses those failures.

On 4/7/20 7:22 PM, Clebert Suconic wrote:

I asked Justin, and he will try for it... if it's just a day or two
delay we should probably wait. if it delays any further that's what I
meant for another release in about a month.

On Tue, Apr 7, 2020 at 5:24 PM Michael Pearce  wrote:

Is it worth getting the queue config refactor in before this release? That
Justin has worked on. That way we can have a release with the refactor and
then the test cases could be refactored for the following release.





On Tue, 7 Apr 2020, 17:57 Clebert Suconic, 
wrote:


I am planning a release on April 13th.

and at least for the short term I want to keep a more frequent release
schedule, with another one in the first week of May. which I will send
another heads up by the end of this month.


There are a lot of good enhancements to be released now.. good fixes.
The testsuite is quite stable on my long running internal jenkins
instance (nothing fancy.. just running the whole testsuite daily).


so, If we could merge / review the PRs we have now.. and if there is
anyone wanting to hold a bit. .this is channel to discuss about it.


Thanks

--
Clebert Suconic






--
Tim Bish

Re: ActiveMQ Redelivery not working with new transaction in consumer

2020-03-28 Thread Timothy Bish 



Please direct support questions to the ActiveMQ Users mailing list as 
this list if for discussion of development of the broker itself.


On 3/28/20 5:17 AM, vedion wrote:

Hi,

I have a ActiveMQ where I have setup Redelivery on the client side. With a
simple consumer it works as expected with the below configurations:

```
import org.apache.activemq.ActiveMQXAConnectionFactory;
import org.apache.activemq.RedeliveryPolicy;
import org.springframework.boot.jta.atomikos.AtomikosConnectionFactoryBean;
import org.springframework.jms.config.DefaultJmsListenerContainerFactory;
import org.springframework.jms.config.JmsListenerContainerFactory;
import org.springframework.jms.core.JmsTemplate;
import org.springframework.jms.listener.DefaultMessageListenerContainer;

...
 @Bean
 public ConnectionFactory atomikosConnectionFactoryBean() {
 String mqUrl = System.getenv("MQ_URL");
 AtomikosConnectionFactoryBean atomikos = new
AtomikosConnectionFactoryBean();
 atomikos.setLocalTransactionMode(false);
 atomikos.setMaxPoolSize(10);
 atomikos.setUniqueResourceName("QUEUE_BROKER");

 RedeliveryPolicy redeliveryPolicy = new RedeliveryPolicy();
 redeliveryPolicy.setMaximumRedeliveries(4);
 redeliveryPolicy.setBackOffMultiplier(10);
 redeliveryPolicy.setRedeliveryDelay(1000L);
 redeliveryPolicy.setInitialRedeliveryDelay(1000L);
 redeliveryPolicy.setUseExponentialBackOff(true);
 redeliveryPolicy.setMaximumRedeliveryDelay(8640L);
 ActiveMQXAConnectionFactory xaConnectionFactoryBean = new
ActiveMQXAConnectionFactory(System.getenv("MQ_USERNAME"),
System.getenv("MQ_PASSWORD"), mqUrl);
 xaConnectionFactoryBean.setRedeliveryPolicy(redeliveryPolicy);
 xaConnectionFactoryBean.setNonBlockingRedelivery(true);
 atomikos.setXaConnectionFactory(xaConnectionFactoryBean);
 return atomikos;
 }

 @Bean
 public JmsListenerContainerFactory
jmsListenerContainerFactory(ConnectionFactory connectionFactory,
DefaultJmsListenerContainerFactoryConfigurer configurer) {
 DefaultJmsListenerContainerFactory factory = new
DefaultJmsListenerContainerFactory();
 configurer.configure(factory, connectionFactory);
 factory.setErrorHandler(new EHealthEventErrorHandler());
 factory.setMessageConverter(jacksonJmsMessageConverter());

factory.setCacheLevel(DefaultMessageListenerContainer.CACHE_CONSUMER);

 factory.setDestinationResolver(new EHealthDestinationResolver());
 factory.setSessionTransacted(true);
 return factory;
 }

 @Bean(autowire = Autowire.BY_TYPE)
 public JmsTemplate jmsTemplate() {
 JmsTemplate jmsTemplate = new
JmsTemplate(atomikosConnectionFactoryBean());
 jmsTemplate.setDestinationResolver(new
EHealthDestinationResolver());
 jmsTemplate.setSessionTransacted(true);
 return jmsTemplate;
 }
 ...
```

```
import org.springframework.jms.annotation.JmsListener;
import org.springframework.transaction.annotation.Transactional;

@Transactional
@JmsListener(destination = "XXX")
public void onMessageReceived(XXXEvent event) {
throw new Exception();
}
```


So the above works as expected and the message is redelivered with the
ExponentialBackOff strategy.

BUT it goes sideways when the message consumer (onMessageReceived) calls a
method on a class that sends a message to another queue in a new
transaction.
Then the message is not redelivered if the exception is thrown after the new
transaction have been committed, ex:

```
import org.springframework.transaction.annotation.Transactional;

public class FooClass {
 @Transactional(propagation = Propagation.REQUIRES_NEW)
 public void createInNewTransaction() {
 sendMessageToAnotherQueue();
 }
}
```

```
import org.springframework.jms.annotation.JmsListener;
import org.springframework.transaction.annotation.Transactional;

@Transactional
@JmsListener(destination = "Foo")
public void onMessageReceived(FooEvent event) {
fooClass.createInNewTransaction();
throw new Exception();
}
```


In the stacktrace below it is seen that the
org.apache.activemq.TransactionContext.synchronizations are nulled when
sending the message in the new transaction. The
TransactionContext.synchronizations contains the ActiveMQMessageConsumer
that is used to receive the message and is needed for the redelivery after
the exception is thrown. When this is cleared the message is not
redelivered:


```
private void afterRollback() throws JMSException {
 if (synchronizations == null) {
 return;
 }
...
}
```


It is the method
com.atomikos.datasource.xa.session.BranchEnlistedStateHandler.checkEnlistBeforeUse()
that detects that the transaction context is different and throws an
exception that is catched in

Re: [DISCUSSION] AMQP paging is triggering reencode: it's possible to avoid it?

2020-03-19 Thread Timothy Bish 

On 3/19/20 2:33 PM, Clebert Suconic wrote:

Can we stop doing that check?

If we are out of memory, we could certainly write non durable messages
to disk, but that doesn't mean they became durable.


That has always been my thought in this, it is not suddenly durable 
simply because it was paged.





On Thu, Mar 19, 2020 at 12:21 PM Timothy Bish  wrote:

On 3/19/20 9:43 AM, nigro_franz wrote:

HI folks,

I'm thinking how to improve (the performance and stability) of AMQP paging
and I've fallen into this behaviour for paging AMQ standard messages:
https://github.com/apache/activemq-artemis/blob/d5104656f9060d347b326c59e136dac0b3c404e0/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessage.java#L840


This reencode() is a very intensive operation and is being triggered on
depaging (exactly here
https://github.com/apache/activemq-artemis/blob/51c2022f388a5c70adbc5de6b799f9072960c2f1/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/PagedReferenceImpl.java#L154).
It force non durable AMQP messages to see their AMQP header to be created,
if not present, just to set that property: given that the header part of
AMQP messages is encoded at the beginning of the message, it forces a
reencode of the whole message.
I suppose this could be improved in different ways, but I was thinking to
always preset an header with durable == false in ((when appropriate, with
non-durable messages): it would make every non durable messages a lil
bigger, but will save lot of memory and CPU time on depaging, because the
reencode could be optimized and be partial (reencoding only the few bits
necessary on the header, now present).

If the broker is going to update the message as it comes out of the
journal to indicate it has become durable then why not beat that to the
punch by just putting it in there that way when there no Header or the
existing Header is marked as non-durable?

* In the case of not having a header you'd then only need to first write
one and then the remaining already encoded message portion.

* In the case that there was a Header I think the AMQPMessage tracks
those location so you could update and re-encode only the Header and
then do as above and just write out the remainder of the previously
encoded message.

I wouldn't just add a Header to every message though as the broker
really should just relay the message as is if it didn't need to store it
in the first place.  I've always been a bit dubious on the whole marking
it durable just because it was paged thing but that might just be me.


I'm opened to discuss this and find together a smart way to improve
depaging: given that it happens when the JVM memory is supposed to be
precious I believe that saving time/memory there is crucial not just for
performance but for the broker stability.

Cheers,
Franz



I've already opened
https://issues.apache.org/jira/browse/ARTEMIS-2661 to improve AMQP journal
loading by saving scanning AMQP message data if not strictly necessary and
it already deliver exceptional result: I would like to do the same on
paging, given that this really seems a low hanging fruit with an high
potential of improvement.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


--
Tim Bish





--
Tim Bish

Re: [DISCUSSION] AMQP paging is triggering reencode: it's possible to avoid it?

2020-03-19 Thread Timothy Bish 

On 3/19/20 9:43 AM, nigro_franz wrote:

HI folks,

I'm thinking how to improve (the performance and stability) of AMQP paging
and I've fallen into this behaviour for paging AMQ standard messages:
https://github.com/apache/activemq-artemis/blob/d5104656f9060d347b326c59e136dac0b3c404e0/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessage.java#L840


This reencode() is a very intensive operation and is being triggered on
depaging (exactly here
https://github.com/apache/activemq-artemis/blob/51c2022f388a5c70adbc5de6b799f9072960c2f1/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/PagedReferenceImpl.java#L154).
It force non durable AMQP messages to see their AMQP header to be created,
if not present, just to set that property: given that the header part of
AMQP messages is encoded at the beginning of the message, it forces a
reencode of the whole message.
I suppose this could be improved in different ways, but I was thinking to
always preset an header with durable == false in ((when appropriate, with
non-durable messages): it would make every non durable messages a lil
bigger, but will save lot of memory and CPU time on depaging, because the
reencode could be optimized and be partial (reencoding only the few bits
necessary on the header, now present).


If the broker is going to update the message as it comes out of the 
journal to indicate it has become durable then why not beat that to the 
punch by just putting it in there that way when there no Header or the 
existing Header is marked as non-durable?


* In the case of not having a header you'd then only need to first write 
one and then the remaining already encoded message portion.


* In the case that there was a Header I think the AMQPMessage tracks 
those location so you could update and re-encode only the Header and 
then do as above and just write out the remainder of the previously 
encoded message.


I wouldn't just add a Header to every message though as the broker 
really should just relay the message as is if it didn't need to store it 
in the first place.  I've always been a bit dubious on the whole marking 
it durable just because it was paged thing but that might just be me.



I'm opened to discuss this and find together a smart way to improve
depaging: given that it happens when the JVM memory is supposed to be
precious I believe that saving time/memory there is crucial not just for
performance but for the broker stability.

Cheers,
Franz



I've already opened
https://issues.apache.org/jira/browse/ARTEMIS-2661 to improve AMQP journal
loading by saving scanning AMQP message data if not strictly necessary and
it already deliver exceptional result: I would like to do the same on
paging, given that this really seems a low hanging fruit with an high
potential of improvement.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html



--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.15.12 release (take #2)

2020-03-16 Thread Timothy Bish 

On 3/13/20 9:43 AM, Jean-Baptiste Onofre wrote:

Hi everyone,

I'm submitting ActiveMQ 5.15.12 release to your vote (take #2). In this new 
round, we fixed JDBC lock test and STOMP connection error handling.

As for the previous attempt, this release includes dependency updates 
(especially for CVE/Security
fixes), important improvements on JDBC persistence adapter, other improvements 
and fixes.

Please take a look on the Release Notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12346500 
>

The Maven staging repository is:
https://repository.apache.org/content/repositories/orgapacheactivemq-1205

The dist staging repository is:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.12/ 
 
>

Git tag:
activemq-5.15.12

Website PR:
https://github.com/apache/activemq-website/pull/28 
 
>

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB


+1


* Validated signatures and checksums
* Verified license and notice files in archives and source
* Ran binary release broker and check web console works
* Built from source package and ran tests


--
Tim Bish

Re: [HEADS UP] Apache ActiveMQ 5.15.12 and ActiveMQ 5.16.0

2020-01-28 Thread Timothy Bish 

On 1/28/20 2:22 PM, Christopher Shannon wrote:

We definitely do not want to remove JDK 8 support for 5.16.0 so my vote is
for option 1.  I think it's fine if we build with JDK 8 as long as it
supports JDK 8 - 11 at runtime.

For 5.17.0 we can work on building with JDK 11.  For one thing I think we
should just make it easier on ourselves and remove LevelDB entirely as it
has been deprecated now for several major versions and there isn't any
reason to keep it at around at this point.



+1




On Tue, Jan 28, 2020 at 7:58 AM Jean-Baptiste Onofré 
wrote:


Hi guys,

I would like to move forward on ActiveMQ releases:

- ActiveMQ 5.15.12
I'm preparing several dependency updates and important fixes on the
activemq-5.15.x branch. It includes some security fixes, postgresql jdbc
store performance improvements, ...
I have some PRs under review and on the fly, so, I plan to submit
5.15.12 to vote next week.

- ActiveMQ 5.16.0
I did a full pass (standalone and in Apache Karaf) with JDK 11. The
broker works without problem, including on Karaf 4.2.8.
However, it's not currently possible to fully build with JDK 11. I have
a branch where I did the required changes (remove the use of tools.jar
in openwire generator, add annotation and jaxb dependency in different
modules, update scala for leveldb, ...).
The question that I have is about what's the exact target for 5.16.0:
1. We still build ActiveMQ 5.16.x with JDK8, but it supports both JDK8
or JDK11 at runtime.
2. I do the changes required to build with JDK11, and then we will only
support JDK11 at runtime.
Thoughts ?
Anyway, I would like to submit 5.16.0 to vote asap, so please, let me
know what you think about JDK support (build or/and runtime).

Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com



--
Tim Bish

Re: Getting error "the client and server cannot communicate, because they do not possess a common algorithm" on .Net Framework 4.0 with TLS 1.2 settings and using Apache.NMS 1.7.1 and Apache.NMS.Activ

2019-11-04 Thread Timothy Bish 
Please direct support questions to the users mailing list, this list is 
for discussion of development of the ActiveMQ project and not meant for 
user support questions.


On 11/4/19 11:32 AM, adongare wrote:

Hi team,

Getting error "the client and server cannot communicate, because they do not
possess a common algorithm" on .Net Framework 4.0 with TLS 1.2 settings and
using Apache.NMS 1.7.1 and Apache.NMS.ActiveMQ 1.7.2 Nuget packages

I am trying to connect ActiveMQ server after migrating my code to TLS 1.2
and getting below error while creating the session. Below line is erroing
out.

this.Session = this.Connection.CreateSession(acknowledgementMode);

Below is my c# code:

protected virtual void CreateSession(AcknowledgementMode
acknowledgementMode)
{
 ServicePointManager.SecurityProtocol =
(SecurityProtocolType)3072 | SecurityProtocolType.Tls;
 
			var connectionFactory = new NMSConnectionFactory(this.BrokerUri);


this.Connection = connectionFactory.CreateConnection();
this.Session = 
this.Connection.CreateSession(acknowledgementMode);
this.Destination = 
this.Session.GetDestination(this.DestinationName,
this.DestinationType);
}

Below is Error stack trace:

System.Security.Authentication.AuthenticationException: A call to SSPI
failed, see inner exception. ---> System.ComponentModel.Win32Exception: The
client and server cannot communicate, because they do not possess a common
algorithm
--- End of inner exception stack trace ---
at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken
message, AsyncProtocolRequest asyncRequest, Exception exception)
at
System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken
message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32
count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst,
Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult
lazyResult)
at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost,
X509CertificateCollection clientCertificates, SslProtocols
enabledSslProtocols, Boolean checkCertificateRevocation)
at Apache.NMS.ActiveMQ.Transport.Tcp.SslTransport.CreateSocketStream()

the attached image has TLS 1.2 setting  on my development machine:


I tried many solutions by searcing online but noting worked. Could you
please help me?




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html



--
Tim Bish

Re: [DISCUSS] ActiveMQ 5.16.0 minimum Java version

2019-10-31 Thread Timothy Bish 

On 10/31/19 6:02 AM, Jean-Baptiste Onofré wrote:

Hi guys,

As I'm working on 5.16.0 release preparation, it's important to agree
about the minimum Java version for runtime of this version.

The purpose is to fully support JDK 9+ (and so 11, 12, 13).

I started some upgrade to fully support those Java versions (for
instance Derby 10.15.1.3 upgrade).

We have two options here:

- still support JDK8 and run with newer version (and then, we have to
keep JDK8 compliant dependencies, like Derby 10.14.2.0 for instance)
- define JDK9 as minimum version to run and then, we can upgrade the
dependencies.

Thoughts ?

Regards
JB


Given how long folks have been waiting on a 5.16.0 release I'd go with 
option 2 and continue supporting JDK 8 so that a new release that can 
run on newer JDKs is out but still maintains compatibility with the 
existing supported platform.


Once 5.16.0 is out then a move to JDK 11 in 5.17.0 if such a release was 
ever to be done would be the next most sensible option as that moves to 
supported JDK.


--
Tim Bish

Re: [VOTE] ActiveMQ Artemis Native 1.0.1

2019-10-23 Thread Timothy Bish 



+1

* Validated signatures and checksums
* Checked the license and notice files
* Compiled using both the native and docker build scripts
* Ran the maven build and tests




On 10/23/19 3:35 PM, Clebert Suconic wrote:

Ping @Everybody... I need votes here..


Vote for me!


I intend to put this release on the next artemis release, so I need
this before we can cut a new release.


Thanks

On Mon, Oct 21, 2019 at 1:41 PM Clebert Suconic
 wrote:

+1 (Binding)

- wiped out my local maven repository
- Added the maven repository into my settings, following instructions
from 
https://activemq.apache.org/components/artemis/documentation/latest/hacking-guide/validating-releases.html
(used maven repo at
https://repository.apache.org/content/repositories/orgapacheactivemq-1199)
- Removed my local maven repository, to make I wouldn't have any local
cached downloads to validate the release.
- Built and ran tests on ActiveMQ Artemis, validating the native bits
are working

On Mon, Oct 21, 2019 at 1:37 PM Clebert Suconic
 wrote:

I would like to propose an Apache ActiveMQ Artemis Native 1.0.1 release.

This is a sub component of ActiveMQ Artemis Native,

Source distribution can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis-native/1.0.1/

Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1199

The source tag:
https://gitbox.apache.org/repos/asf?p=activemq-artemis-native.git;a=tag;h=refs/tags/1.0.1

This release only has basic changes on META-INF allowing load of
native bits on OSGI and the possibility of having other platforms
loaded.

The release notes will have a more complete view of the two changes
I'm talking about:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12345696


[ ] +1 approve the release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


I will record my VOTE on a response to my own email.



--
Clebert Suconic





--
Tim Bish

Re: The best forum for Artemis configuration questions

2019-10-09 Thread Timothy Bish 

On 10/9/19 2:18 PM, wazburrows wrote:

Hi dev team,

I'm posting this to the dev mailing list because I see a lot activity on the
dev list around the recent Active MQ and Artemis releases here and was
hoping to get direction from the dev team. My question to you is where is
the best place for Artemis usage/configuration questions?  I have an issue
with collocated HA fail-back on Artemis that I can't figure out and haven't
gotten a response on the user mailing list/forum (except for my own
follow-up). Is there another more active user forum that I should to post
questions to?

Thanks




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html


You should post your questions on the users mailing list.

--
Tim Bish

Re: [VOTE[ Release Apache NMS AMQP 1.8.0

2019-10-03 Thread Timothy Bish 

-1 (binding)

On 10/3/19 3:30 PM, Krzysztof wrote:

Hi Robbie,

Ad 1: Could you elaborate a little about this? I've just downloaded all the
bits to my home machine, unpacked it, and removed successfully.


I've downloaded the binaries and can confirm that on a linux machine the 
src archive extracts and then cannot be removed without an sudo to force 
remove the files that have permission issues.


rm -rf test/
rm: cannot remove 'test/Apache-NMS-AMQP-Test/Test/Util': Permission denied
rm: cannot remove 'test/Apache-NMS-AMQP-Test/Test/Attribute': Permission 
denied
rm: cannot remove 'test/Apache-NMS-AMQP-Test/Test/TestCase': Permission 
denied




Ad 2: I've submitted PR which adds missing license headers.

Thank you so much for feedback. I hope that next spin will be
more successful.

On Thu, Oct 3, 2019 at 9:17 PM Clebert Suconic 
wrote:


+1

On Thu, Oct 3, 2019 at 11:57 AM Robbie Gemmell 
wrote:


-1  (non-binding)

- There is content in the archive permissioned in a way that you cant
access / delete it once you extract it, a little like the initial
1.8.0 API RC archive had.
- There are some files that should have headers which dont. Unfiltered
RAT output summary below.

Seperately from that, I'd suggest having a parent dir for the
contents, unless theres a reason it isnt possible? Most releases have
them and I'd say its far nicer overall but particularly when extracing
things, and also helps when e.g .dll's dont have version numbers in
their filename. I tend to make the source one differ with a -src
suffix to aid side by side extraction also.

I guess 1.8.0 was selected given prior versioning behaviour for some
of the other NMS impls? Feels a little strange for the first release,
plus is that meaning only 1.8.x releases until the API changes? Now
would seem to be the best time to do something different if it was
thought desirable.

Robbie


*
Summary
---
Generated at: 2019-10-03T16:13:46+01:00

Notes: 2
Binaries: 3
Archives: 0
Standards: 225

Apache Licensed: 201
Generated Documents: 0

JavaDocs are generated, thus a license header is optional.
Generated files do not require license headers.

24 Unknown Licenses

*

Files with unapproved licenses:

   ./README.md
   ./apache-nms-amqp.sln
   ./src/NMS.AMQP/NmsDurableTopicSubscriber.cs
   ./src/NMS.AMQP/Meta/TransactionInfo.cs
   ./src/PingPong/Ping.cs
   ./src/PingPong/PingPong.csproj
   ./src/PingPong/Pong.cs
   ./src/PingPong/Program.cs
   ./src/PingPong/Stats.cs
   ./test/Apache-NMS-AMQP-Test/NLog.config
   ./test/Apache-NMS-AMQP-Test/TestSuite.config



./test/Apache-NMS-AMQP-Test/Integration/MessageExpirationIntegrationTest.cs

   ./test/Apache-NMS-AMQP-Test/TestAmqp/NLogAdapter.cs
   ./test/Apache-NMS-AMQP-Test/TestAmqp/BasicTypes/ConnectionError.cs
   ./test/Apache-NMS-AMQP-Test/TestAmqp/BasicTypes/FrameCodes.cs
   ./test/Apache-NMS-AMQP-Test/TestAmqp/BasicTypes/TerminusExpiryPolicy.cs
   ./test/Apache-NMS-AMQP-Test/config/Adapter.runsettings
   ./test/Apache-NMS-AMQP-Test/config/cert/ReadMe.md
   ./test/Apache-NMS-AMQP-Test/config/cert/broker.crt
   ./test/Apache-NMS-AMQP-Test/config/cert/broker.key
   ./test/Apache-NMS-AMQP-Test/config/cert/ca.crt
   ./test/Apache-NMS-AMQP-Test/config/cert/ca.key
   ./test/Apache-NMS-AMQP-Test/config/cert/client.crt
   ./test/Apache-NMS-AMQP-Test/config/cert/client.key

*

On Thu, 3 Oct 2019 at 11:49, Michael Pearce 
wrote:

Hi All,

I have put together a spin for a Apache NMS AMQP release, please
check it and vote accordingly.

This release effectively will be the first release of a NMS AMQP

client..

Also includes some modernisation of the project that was needed to
make the release, updating for latest visual studio, and lastly,
creating a nuget package, that once approved, we can publish to nuget.

The files can be grabbed
from:

https://dist.apache.org/repos/dist/dev/activemq/activemq-nms-amqp/1.8.0-rc1/

The JIRAs assigned for this release can be found:



https://issues.apache.org/jira/browse/AMQNET-618?jql=project%20%3D%20AMQNET%20AND%20fixVersion%20%3D%201.8.0%20AND%20component%20%3D%20AMQP



Regards,
Michael

--
Clebert Suconic



--
Tim Bish

Re: [RESULT][VOTE] Apache ActiveMQ Artemis 2.10.1

2019-10-01 Thread Timothy Bish 



On 10/1/19 8:29 PM, Clebert Suconic wrote:

I have already updated the website and will send the announce tomorrow.

Meanwhile if you guys could check the website and everything else please?
Just in case I missed anything?



Broken link on past releases page for GPG signature of 2.10.0 bin.zip



On Thu, Sep 26, 2019 at 5:18 PM Clebert Suconic 
wrote:


Results of the Apache ActiveMQ Artemis 2.10.1 release vote:

Vote passes with 10 +1 votes (6 bindings, 4 non bindings)


Binding:

Clebert Suconic
Timothy Bish
Gary Tully
Cristopher Shannon
Justin Bertram
Michael Andre Pearce

Non Binding:

Francesco Nigro
Howard Gao
Emmanuel Hugonnet
Krzysztof Porebski


Really thanks for everyone who contributed, took time to review and
voted for the release candidate.


I will move forward with getting updating documentation, website. I
will send the announce around tomorrow  when everything is ready.


Thanks

On Thu, Sep 26, 2019 at 12:33 PM 
wrote:

+1


Validated checksum and signatures


Started broker from binary and ran smoke tests with core and amqp java

client




Get Outlook for Android







On Thu, Sep 26, 2019 at 3:10 PM +0100, "Justin Bertram" <

jbert...@apache.org> wrote:










Looks good to me.

+1


Justin

On Mon, Sep 23, 2019 at 3:26 PM Clebert Suconic
wrote:


I would like to propose an Apache ActiveMQ Artemis 2.10.1 Release.

The release contains bug fixes and improvements as you can see on the
release report:



https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346078

The commit report:



https://activemq.apache.org/components/artemis/download/commit-report-2.10.1

Source and binary distribution:


https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.10.1/

The maven repository:


https://repository.apache.org/content/repositories/orgapacheactivemq-1198

In case you want to give it a try with the maven repo on examples:



http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html


The source tag:



https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.10.1

I will update the website after the vote has passed.


[ ] +1 approve the release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1


--
Clebert Suconic








--
Clebert Suconic



--
Tim Bish

Re: [VOTE] Apache ActiveMQ Artemis 2.10.1

2019-09-26 Thread Timothy Bish 

On 9/23/19 4:26 PM, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.10.1 Release.

The release contains bug fixes and improvements as you can see on the
release report:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920=12346078

The commit report:
https://activemq.apache.org/components/artemis/download/commit-report-2.10.1

Source and binary distribution:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.10.1/

The maven repository:
https://repository.apache.org/content/repositories/orgapacheactivemq-1198

In case you want to give it a try with the maven repo on examples:
http://activemq.apache.org/artemis/docs/latest/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.10.1

I will update the website after the vote has passed.


[ ] +1 approve the release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here's my +1




+1

* Validated signatures and checksums
* Verified license and notice files are present in archives
* Checked code for license headers using apache rat
* Ran binary broker build and tested web console
* Ran Qpid JMS Hello World against binary broker run
* Built from source and ran some of the tests including all AMQP tests.


--
Tim Bish

Re: ActiveMQ 5.15.10 not yet advertised on website

2019-09-12 Thread Timothy Bish 
Is there some hurdle that is holding up the process?  Seems like we should
have an announce thread by now and the site should be updated.

On Fri, Sep 6, 2019 at 1:27 AM Jean-Baptiste Onofré  wrote:

> Hi,
>
> It's on the way, I'm preparing the website update. Chris helped me to
> finalize the release (publishing on dist.apache.org), so, now I'm moving
> forward on the website update and announcement e-mail.
>
> Sorry for the delay.
>
> Regards
> JB
>
> On 06/09/2019 04:43, W B D wrote:
> > I saw that the vote passed for the release of 5.15.10, and that the maven
> > repository and download folder are both in place, but the website still
> > indicates 5.15.9 as the current release. Did something go wrong with the
> > publishing process?
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


-- 
--
Tim Bish

Re: Artemis past releases page breakages

2019-09-06 Thread Timothy Bish 
It would appear that this problem has occurred again.  The past releases
page was partially updated but in all cases the updates were incorrect and
now the download links are broken.  The links to the all broker release
archives themselves point to Apache Archives but the action=download bit at
the end of the URI was not removed.  The links to the checksums and
signatures were not updated to point to archives it seems and so those are
also broken.

On Mon, Jun 3, 2019 at 6:44 AM Robbie Gemmell 
wrote:

> Its more that the download links for the previous release themselves
> are broken thats the issue. The docs link is often incorrect too, but
> it tends to at least somewhat 'work' when wrong (from pointing to
> "latest" rather than the actual versions release docs).
>
> I think the existing process needed (copy+paste the previous entry in
> file, find+replace the version number) is actually fairly easy. Its
> just not being followed, and the links also arent being inspected
> afterwards to notice that it wasnt.
>
> Robbie
>
> On Fri, 31 May 2019 at 17:25, Clebert Suconic 
> wrote:
> >
> > Please accept my apologies... I have been on so many channels all at
> > once that I overlooked into this.
> >
> > it would be nice to make this simpler though. I have tried to get rid
> > of the documentation per previous version for instance (you can just
> > download the documentation with the zip).
> >
> > On Fri, May 31, 2019 at 5:35 AM Robbie Gemmell 
> wrote:
> > >
> > > Yes it is, I even noted I found it was already documented when I went
> > > to add one of the times I was reporting the issue.
> > >
> > >
> https://github.com/apache/activemq-artemis/blame/2.8.1/RELEASING.md#L299
> > > (The details are a touch stale now in referring to html of the old
> > > site update process)
> > >
> > > On Fri, 31 May 2019 at 10:22, Gary Tully  wrote:
> > > >
> > > > is that step in:
> > > > https://github.com/apache/activemq-artemis/blob/master/RELEASING.md
> > > >
> > > >
> > > > On Thu, 30 May 2019 at 12:29, Robbie Gemmell <
> robbie.gemm...@gmail.com> wrote:
> > > > >
> > > > > I've found that the docs/downloads/etc links for recent releases on
> > > > > the past releases page are broken nearly every time I have used the
> > > > > page over the last couple of years. I've fixed it a bunch of times,
> > > > > reported it several times to try and stop it from actually
> happening,
> > > > > and fixed it some more times as it keeps doing so.
> > > > >
> > > > > It is difficult to understand how the same issue keeps happening
> > > > > repeatedly given how trivial the page is to update and how
> quick/easy
> > > > > it is to verify the links while doing so, e.g by hovering over
> them,
> > > > > or actually clicking them like a user might and see them 404 or go
> the
> > > > > wrong place if the files havent been cleared from the mirroring
> area
> > > > > just yet.
> > > > >
> > > > > As the page is proving so troublesome to maintain in working
> order, I
> > > > > think the per-release content might be better jsut removed and only
> > > > > the direct link to the archive parent dir left. Thats where I will
> be
> > > > > going directly in future to save myself the hassle (of noticing the
> > > > > page is broken and feeling I should report it or fix it yet again).
> > > > >
> > > > > Robbie
> >
> >
> >
> > --
> > Clebert Suconic
>


-- 
--
Tim Bish

Re: [VOTE] Apache ActiveMQ 5.15.10 release (take #4)

2019-08-28 Thread Timothy Bish 

On 8/28/19 6:21 AM, Jean-Baptiste Onofré wrote:

Hi guys,

I'm submitting ActiveMQ 5.15.10 release to your vote.

This release includes dependency updates, and improvements.

Please take a look on the Release Notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12345171

The Maven staging repository is:
https://repository.apache.org/content/repositories/orgapacheactivemq-1196

The dist staging repository is:
https://dist.apache.org/repos/dist/dev/activemq/activemq/5.15.10/

Git tag:
activemq-5.15.10

NOTE: I'm preparing a release notes highlights for the website,
especially to mention the updates related to CVE issues.

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks !
Regards
JB



+1

* Validated signatures and checksums
* Checked binaries for license and notice files
* Validated source headers using apache-rat
* Built from source and ran the tests
* Ran the broker instance from the binary distribution and checked the 
web console

* Ran some AMQP client examples against the running broker


--
Tim Bish

  1   2   3   4   5   6   7   8   9   10   >