You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Justin Bertram <jb...@apache.org> on 2024/10/21 19:04:44 UTC
[CANCEL][VOTE] Apache ActiveMQ Artemis 2.38.0
I'm cancelling this vote due to the build-reproducibility issue that Robbie
outlined.
Justin
On Mon, Oct 21, 2024 at 1:58 PM Justin Bertram <jb...@apache.org> wrote:
> For the sake of clarity and consistency I'm going to cancel this vote,
> re-spin to fix the build-repeatability issue, and send another vote.
>
> Thanks for testing this, Robbie!
>
>
> Justin
>
> On Mon, Oct 21, 2024 at 9:39 AM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> As an explainer, the cause for the reproducibility check failing looks
>> to be from a difference in umask between Justin's env and those used
>> for previous releases and in turn the Reproducible Central buildspec
>> used to verify the reproducibility.
>>
>> On previous systems that did the release, a umask of [0]022 was in
>> effect. On Justins, a umask of [0]002 was in effect. When I changed
>> umask to [0]002 I was then able to do a 100% reproduction of the
>> build.
>>
>> I'm not yet clear on why, but for the 3 war files in the build, the
>> permissions on the embedded maven detail files (but none of the actual
>> content files) are influenced by the umask:
>> META-INF/maven/<groupId>/<artifact-id>/pom.xml
>> META-INF/maven/<groupId>/<artifact-id>/pom.properties
>>
>> The war files contents then in turn influence the binary assembly and
>> related checksum files, giving a total of 7 differences in the overall
>> build. None of the 'actual content' differs as such, just the
>> permissions, the metadata for which throws off the overall assembly.
>>
>> The same type of generated files are also embedded in all the jar
>> files, but are not influenced by the differing umasks so the jars all
>> came out the same regardless.
>>
>> We could either proceed and try to update the buildspec at
>> Reproducible Central to compensate (and then need to update it again
>> to switch back in future if we make things consistent). Or we could
>> redeploy the build to make this consistent with prior releases, the
>> binary assembly and sig+checksum would get updated, as would the sig
>> for the source release (embedded timestamp) though not the source
>> archive itself.
>>
>> Thoughts, Justin?
>>
>> On Fri, 18 Oct 2024 at 17:26, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>> >
>> > -1, for now at least.
>> >
>> > The deployed convenience binaries failed a reproducibility check, even
>> > though all the sub-content in them ultimately seems to be the same as
>> > in the rebuild. A permissions difference in a few modules (the 3
>> > console war files) META-INF files seems to be the cause, which in turn
>> > rippled through to the binary assembly archives as a whole.
>> >
>> > I'd like to try some redeployments on Monday to see whether we could
>> > resolve the issue, or at least isolate a reason/env-difference that
>> > prompts it.
>> >
>> > Note -1's are not a veto on releases, and even with my -1 it still
>> > meets the criteria necessary to proceed, i.e can currently still be
>> > released as-is if so desired.
>> >
>> > I checked things over as follows:
>> > - Verified the signature + checksum files.
>> > - Checked for LICENCE + NOTICE files in the archives.
>> > - Checked licence headers in the source archive by running:
>> > "mvn apache-rat:check"
>> > - Ran the Qpid JMS 2.6.1 HelloWorld against a broker from the binary
>> > archive on JDK 17.
>> > - Ran the source build and the AMQP integration tests on JDK 17 with:
>> > "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
>> > -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
>> > test"
>> > - Verified the build reproducibility using the tooling at Reproducible
>> > Central, which failed as per above.
>> >
>> > Robbie
>> >
>> > On Wed, 16 Oct 2024 at 17:13, Justin Bertram <jb...@apache.org>
>> wrote:
>> > >
>> > > I would like to propose an Apache ActiveMQ Artemis 2.38.0 release.
>> > >
>> > > Highlights include:
>> > >
>> > > - WebSocket compression is now supported. This compression can be used
>> > > transparently for AMQP, STOMP, or MQTT when communication is over
>> > > WebSockets.
>> > > - The ActiveMQServerMessagePlugin now has a messageMoved() callback.
>> > > - Core bridge configuration now supports client-id which will make it
>> much
>> > > easier to identify bridge connections on remote brokers.
>> > > - The consumer CLI command now supports consuming messages "forever."
>> > > - The authentication & authorization caches now have detailed debug
>> logging.
>> > > - There’s been a handful of updates to broker management including:
>> > > - The documentation has been improved with more examples for
>> Jolokia
>> > > and a new sub-section on management method option syntax.
>> > > - It’s now possible to pass empty "options" to the management
>> methods
>> > > that accept them.
>> > > - The management methods which return paged results can now
>> return all
>> > > the results together by specifying -1 for either the page or the
>> pageSize.
>> > > - The management method option syntax now supports the NOT_EQUALS
>> > > operator for greater flexibility with filtering results of management
>> > > operations.
>> > > - Configuration for diverts created via management can now be
>> done via
>> > > JSON.
>> > >
>> > > The release notes can be found here:
>> > >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12355013
>> > >
>> > > Ths git commit report is here:
>> > >
>> https://activemq.apache.org/components/artemis/download/commit-report-2.38.0
>> > >
>> > > Source and binary distributions can be found here:
>> > >
>> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.38.0/
>> > >
>> > > The Maven staging repository is here:
>> > >
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1410
>> > >
>> > > 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 <version>
>> > >
>> > > [ ] +1 approve this release
>> > > [ ] +0 no opinion
>> > > [ ] -1 disapprove (and reason why)
>> > >
>> > > Here's my +1
>> > >
>> > >
>> > > Justin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
>> For additional commands, e-mail: dev-help@activemq.apache.org
>> For further information, visit: https://activemq.apache.org/contact
>>
>>
>>
Re: [CANCEL][VOTE] Apache ActiveMQ Artemis 2.38.0
Posted by Clebert Suconic <cl...@gmail.com>.
Just a brainstorm. Isn’t this something apache parent should prevent? Or
maybe the Maven release plugin?
Clebert Suconic
On Tue, Oct 22, 2024 at 8:21 AM Robbie Gemmell <ro...@gmail.com>
wrote:
> PR merged, and followed up with reworked addition around checking the
> reproducibility:
>
>
> https://github.com/apache/activemq-artemis/blob/main/RELEASING.adoc#verify-build-reproducibility
>
> https://github.com/apache/activemq-artemis/commit/ef09a95fb206af49bc91c0b4966f15075b292c10
>
> On Tue, 22 Oct 2024 at 12:31, Robbie Gemmell <ro...@gmail.com>
> wrote:
> >
> > Well, crap...I just added a whole section about the reproducibility
> > checks before seeing this, and hadn't noticed your other PR. I'll
> > review the PR and perhaps revert my change, merge, and then redo it.
> >
> > On Mon, 21 Oct 2024 at 22:03, Justin Bertram <jb...@apache.org>
> wrote:
> > >
> > > I plan on adding steps to the release documentation to mitigate this
> in the
> > > future including how to verify reproducibility.
> > >
> > > At the moment I already have a PR [1] for other, unrelated updates to
> the
> > > release doc that I'd like to get merged first, though.
> > >
> > >
> > > Justin
> > >
> > > [1] https://github.com/apache/activemq-artemis/pull/5304
> > >
> > > On Mon, Oct 21, 2024 at 3:59 PM Clebert Suconic <
> clebert.suconic@gmail.com>
> > > wrote:
> > >
> > > > I don't understand how to avoid this in the future... and how to
> check it?
> > > > I think we should update the RELEASE.md with steps to verify and
> avoid it
> > > > but I don't understand it 100%.. just that something got the wrong
> mask on
> > > > Justin's env causing a reproducing issue.
> > > >
> > > > Clebert Suconic
> > > >
> > > >
> > > > On Mon, Oct 21, 2024 at 3:05 PM Justin Bertram <jb...@apache.org>
> > > > wrote:
> > > >
> > > > > I'm cancelling this vote due to the build-reproducibility issue
> that
> > > > Robbie
> > > > > outlined.
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > On Mon, Oct 21, 2024 at 1:58 PM Justin Bertram <
> jbertram@apache.org>
> > > > > wrote:
> > > > >
> > > > > > For the sake of clarity and consistency I'm going to cancel this
> vote,
> > > > > > re-spin to fix the build-repeatability issue, and send another
> vote.
> > > > > >
> > > > > > Thanks for testing this, Robbie!
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > On Mon, Oct 21, 2024 at 9:39 AM Robbie Gemmell <
> > > > robbie.gemmell@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> As an explainer, the cause for the reproducibility check
> failing looks
> > > > > >> to be from a difference in umask between Justin's env and those
> used
> > > > > >> for previous releases and in turn the Reproducible Central
> buildspec
> > > > > >> used to verify the reproducibility.
> > > > > >>
> > > > > >> On previous systems that did the release, a umask of [0]022 was
> in
> > > > > >> effect. On Justins, a umask of [0]002 was in effect. When I
> changed
> > > > > >> umask to [0]002 I was then able to do a 100% reproduction of the
> > > > > >> build.
> > > > > >>
> > > > > >> I'm not yet clear on why, but for the 3 war files in the build,
> the
> > > > > >> permissions on the embedded maven detail files (but none of the
> actual
> > > > > >> content files) are influenced by the umask:
> > > > > >> META-INF/maven/<groupId>/<artifact-id>/pom.xml
> > > > > >> META-INF/maven/<groupId>/<artifact-id>/pom.properties
> > > > > >>
> > > > > >> The war files contents then in turn influence the binary
> assembly and
> > > > > >> related checksum files, giving a total of 7 differences in the
> overall
> > > > > >> build. None of the 'actual content' differs as such, just the
> > > > > >> permissions, the metadata for which throws off the overall
> assembly.
> > > > > >>
> > > > > >> The same type of generated files are also embedded in all the
> jar
> > > > > >> files, but are not influenced by the differing umasks so the
> jars all
> > > > > >> came out the same regardless.
> > > > > >>
> > > > > >> We could either proceed and try to update the buildspec at
> > > > > >> Reproducible Central to compensate (and then need to update it
> again
> > > > > >> to switch back in future if we make things consistent). Or we
> could
> > > > > >> redeploy the build to make this consistent with prior releases,
> the
> > > > > >> binary assembly and sig+checksum would get updated, as would
> the sig
> > > > > >> for the source release (embedded timestamp) though not the
> source
> > > > > >> archive itself.
> > > > > >>
> > > > > >> Thoughts, Justin?
> > > > > >>
> > > > > >> On Fri, 18 Oct 2024 at 17:26, Robbie Gemmell <
> > > > robbie.gemmell@gmail.com>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > -1, for now at least.
> > > > > >> >
> > > > > >> > The deployed convenience binaries failed a reproducibility
> check,
> > > > even
> > > > > >> > though all the sub-content in them ultimately seems to be the
> same
> > > > as
> > > > > >> > in the rebuild. A permissions difference in a few modules
> (the 3
> > > > > >> > console war files) META-INF files seems to be the cause,
> which in
> > > > turn
> > > > > >> > rippled through to the binary assembly archives as a whole.
> > > > > >> >
> > > > > >> > I'd like to try some redeployments on Monday to see whether
> we could
> > > > > >> > resolve the issue, or at least isolate a
> reason/env-difference that
> > > > > >> > prompts it.
> > > > > >> >
> > > > > >> > Note -1's are not a veto on releases, and even with my -1 it
> still
> > > > > >> > meets the criteria necessary to proceed, i.e can currently
> still be
> > > > > >> > released as-is if so desired.
> > > > > >> >
> > > > > >> > I checked things over as follows:
> > > > > >> > - Verified the signature + checksum files.
> > > > > >> > - Checked for LICENCE + NOTICE files in the archives.
> > > > > >> > - Checked licence headers in the source archive by running:
> > > > > >> > "mvn apache-rat:check"
> > > > > >> > - Ran the Qpid JMS 2.6.1 HelloWorld against a broker from the
> binary
> > > > > >> > archive on JDK 17.
> > > > > >> > - Ran the source build and the AMQP integration tests on JDK
> 17
> > > > with:
> > > > > >> > "mvn clean install -DskipTests && cd
> tests/integration-tests/ &&
> > > > mvn
> > > > > >> > -Ptests
> -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
> > > > > >> > test"
> > > > > >> > - Verified the build reproducibility using the tooling at
> > > > Reproducible
> > > > > >> > Central, which failed as per above.
> > > > > >> >
> > > > > >> > Robbie
> > > > > >> >
> > > > > >> > On Wed, 16 Oct 2024 at 17:13, Justin Bertram <
> jbertram@apache.org>
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > I would like to propose an Apache ActiveMQ Artemis 2.38.0
> release.
> > > > > >> > >
> > > > > >> > > Highlights include:
> > > > > >> > >
> > > > > >> > > - WebSocket compression is now supported. This compression
> can be
> > > > > used
> > > > > >> > > transparently for AMQP, STOMP, or MQTT when communication
> is over
> > > > > >> > > WebSockets.
> > > > > >> > > - The ActiveMQServerMessagePlugin now has a messageMoved()
> > > > callback.
> > > > > >> > > - Core bridge configuration now supports client-id which
> will make
> > > > > it
> > > > > >> much
> > > > > >> > > easier to identify bridge connections on remote brokers.
> > > > > >> > > - The consumer CLI command now supports consuming messages
> > > > > "forever."
> > > > > >> > > - The authentication & authorization caches now have
> detailed
> > > > debug
> > > > > >> logging.
> > > > > >> > > - There’s been a handful of updates to broker management
> > > > including:
> > > > > >> > > - The documentation has been improved with more
> examples for
> > > > > >> Jolokia
> > > > > >> > > and a new sub-section on management method option syntax.
> > > > > >> > > - It’s now possible to pass empty "options" to the
> management
> > > > > >> methods
> > > > > >> > > that accept them.
> > > > > >> > > - The management methods which return paged results can
> now
> > > > > >> return all
> > > > > >> > > the results together by specifying -1 for either the page
> or the
> > > > > >> pageSize.
> > > > > >> > > - The management method option syntax now supports the
> > > > > NOT_EQUALS
> > > > > >> > > operator for greater flexibility with filtering results of
> > > > > management
> > > > > >> > > operations.
> > > > > >> > > - Configuration for diverts created via management can
> now be
> > > > > >> done via
> > > > > >> > > JSON.
> > > > > >> > >
> > > > > >> > > The release notes can be found here:
> > > > > >> > >
> > > > > >>
> > > > >
> > > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12355013
> > > > > >> > >
> > > > > >> > > Ths git commit report is here:
> > > > > >> > >
> > > > > >>
> > > > >
> > > >
> https://activemq.apache.org/components/artemis/download/commit-report-2.38.0
> > > > > >> > >
> > > > > >> > > Source and binary distributions can be found here:
> > > > > >> > >
> > > > > >>
> > > > >
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.38.0/
> > > > > >> > >
> > > > > >> > > The Maven staging repository is here:
> > > > > >> > >
> > > > > >>
> > > > >
> > > >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1410
> > > > > >> > >
> > > > > >> > > 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 <version>
> > > > > >> > >
> > > > > >> > > [ ] +1 approve this release
> > > > > >> > > [ ] +0 no opinion
> > > > > >> > > [ ] -1 disapprove (and reason why)
> > > > > >> > >
> > > > > >> > > Here's my +1
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > Justin
> > > > > >>
> > > > > >>
> ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > > > > >> For additional commands, e-mail: dev-help@activemq.apache.org
> > > > > >> For further information, visit:
> https://activemq.apache.org/contact
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>
Re: [CANCEL][VOTE] Apache ActiveMQ Artemis 2.38.0
Posted by Robbie Gemmell <ro...@gmail.com>.
PR merged, and followed up with reworked addition around checking the
reproducibility:
https://github.com/apache/activemq-artemis/blob/main/RELEASING.adoc#verify-build-reproducibility
https://github.com/apache/activemq-artemis/commit/ef09a95fb206af49bc91c0b4966f15075b292c10
On Tue, 22 Oct 2024 at 12:31, Robbie Gemmell <ro...@gmail.com> wrote:
>
> Well, crap...I just added a whole section about the reproducibility
> checks before seeing this, and hadn't noticed your other PR. I'll
> review the PR and perhaps revert my change, merge, and then redo it.
>
> On Mon, 21 Oct 2024 at 22:03, Justin Bertram <jb...@apache.org> wrote:
> >
> > I plan on adding steps to the release documentation to mitigate this in the
> > future including how to verify reproducibility.
> >
> > At the moment I already have a PR [1] for other, unrelated updates to the
> > release doc that I'd like to get merged first, though.
> >
> >
> > Justin
> >
> > [1] https://github.com/apache/activemq-artemis/pull/5304
> >
> > On Mon, Oct 21, 2024 at 3:59 PM Clebert Suconic <cl...@gmail.com>
> > wrote:
> >
> > > I don't understand how to avoid this in the future... and how to check it?
> > > I think we should update the RELEASE.md with steps to verify and avoid it
> > > but I don't understand it 100%.. just that something got the wrong mask on
> > > Justin's env causing a reproducing issue.
> > >
> > > Clebert Suconic
> > >
> > >
> > > On Mon, Oct 21, 2024 at 3:05 PM Justin Bertram <jb...@apache.org>
> > > wrote:
> > >
> > > > I'm cancelling this vote due to the build-reproducibility issue that
> > > Robbie
> > > > outlined.
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Mon, Oct 21, 2024 at 1:58 PM Justin Bertram <jb...@apache.org>
> > > > wrote:
> > > >
> > > > > For the sake of clarity and consistency I'm going to cancel this vote,
> > > > > re-spin to fix the build-repeatability issue, and send another vote.
> > > > >
> > > > > Thanks for testing this, Robbie!
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > On Mon, Oct 21, 2024 at 9:39 AM Robbie Gemmell <
> > > robbie.gemmell@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> As an explainer, the cause for the reproducibility check failing looks
> > > > >> to be from a difference in umask between Justin's env and those used
> > > > >> for previous releases and in turn the Reproducible Central buildspec
> > > > >> used to verify the reproducibility.
> > > > >>
> > > > >> On previous systems that did the release, a umask of [0]022 was in
> > > > >> effect. On Justins, a umask of [0]002 was in effect. When I changed
> > > > >> umask to [0]002 I was then able to do a 100% reproduction of the
> > > > >> build.
> > > > >>
> > > > >> I'm not yet clear on why, but for the 3 war files in the build, the
> > > > >> permissions on the embedded maven detail files (but none of the actual
> > > > >> content files) are influenced by the umask:
> > > > >> META-INF/maven/<groupId>/<artifact-id>/pom.xml
> > > > >> META-INF/maven/<groupId>/<artifact-id>/pom.properties
> > > > >>
> > > > >> The war files contents then in turn influence the binary assembly and
> > > > >> related checksum files, giving a total of 7 differences in the overall
> > > > >> build. None of the 'actual content' differs as such, just the
> > > > >> permissions, the metadata for which throws off the overall assembly.
> > > > >>
> > > > >> The same type of generated files are also embedded in all the jar
> > > > >> files, but are not influenced by the differing umasks so the jars all
> > > > >> came out the same regardless.
> > > > >>
> > > > >> We could either proceed and try to update the buildspec at
> > > > >> Reproducible Central to compensate (and then need to update it again
> > > > >> to switch back in future if we make things consistent). Or we could
> > > > >> redeploy the build to make this consistent with prior releases, the
> > > > >> binary assembly and sig+checksum would get updated, as would the sig
> > > > >> for the source release (embedded timestamp) though not the source
> > > > >> archive itself.
> > > > >>
> > > > >> Thoughts, Justin?
> > > > >>
> > > > >> On Fri, 18 Oct 2024 at 17:26, Robbie Gemmell <
> > > robbie.gemmell@gmail.com>
> > > > >> wrote:
> > > > >> >
> > > > >> > -1, for now at least.
> > > > >> >
> > > > >> > The deployed convenience binaries failed a reproducibility check,
> > > even
> > > > >> > though all the sub-content in them ultimately seems to be the same
> > > as
> > > > >> > in the rebuild. A permissions difference in a few modules (the 3
> > > > >> > console war files) META-INF files seems to be the cause, which in
> > > turn
> > > > >> > rippled through to the binary assembly archives as a whole.
> > > > >> >
> > > > >> > I'd like to try some redeployments on Monday to see whether we could
> > > > >> > resolve the issue, or at least isolate a reason/env-difference that
> > > > >> > prompts it.
> > > > >> >
> > > > >> > Note -1's are not a veto on releases, and even with my -1 it still
> > > > >> > meets the criteria necessary to proceed, i.e can currently still be
> > > > >> > released as-is if so desired.
> > > > >> >
> > > > >> > I checked things over as follows:
> > > > >> > - Verified the signature + checksum files.
> > > > >> > - Checked for LICENCE + NOTICE files in the archives.
> > > > >> > - Checked licence headers in the source archive by running:
> > > > >> > "mvn apache-rat:check"
> > > > >> > - Ran the Qpid JMS 2.6.1 HelloWorld against a broker from the binary
> > > > >> > archive on JDK 17.
> > > > >> > - Ran the source build and the AMQP integration tests on JDK 17
> > > with:
> > > > >> > "mvn clean install -DskipTests && cd tests/integration-tests/ &&
> > > mvn
> > > > >> > -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
> > > > >> > test"
> > > > >> > - Verified the build reproducibility using the tooling at
> > > Reproducible
> > > > >> > Central, which failed as per above.
> > > > >> >
> > > > >> > Robbie
> > > > >> >
> > > > >> > On Wed, 16 Oct 2024 at 17:13, Justin Bertram <jb...@apache.org>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > I would like to propose an Apache ActiveMQ Artemis 2.38.0 release.
> > > > >> > >
> > > > >> > > Highlights include:
> > > > >> > >
> > > > >> > > - WebSocket compression is now supported. This compression can be
> > > > used
> > > > >> > > transparently for AMQP, STOMP, or MQTT when communication is over
> > > > >> > > WebSockets.
> > > > >> > > - The ActiveMQServerMessagePlugin now has a messageMoved()
> > > callback.
> > > > >> > > - Core bridge configuration now supports client-id which will make
> > > > it
> > > > >> much
> > > > >> > > easier to identify bridge connections on remote brokers.
> > > > >> > > - The consumer CLI command now supports consuming messages
> > > > "forever."
> > > > >> > > - The authentication & authorization caches now have detailed
> > > debug
> > > > >> logging.
> > > > >> > > - There’s been a handful of updates to broker management
> > > including:
> > > > >> > > - The documentation has been improved with more examples for
> > > > >> Jolokia
> > > > >> > > and a new sub-section on management method option syntax.
> > > > >> > > - It’s now possible to pass empty "options" to the management
> > > > >> methods
> > > > >> > > that accept them.
> > > > >> > > - The management methods which return paged results can now
> > > > >> return all
> > > > >> > > the results together by specifying -1 for either the page or the
> > > > >> pageSize.
> > > > >> > > - The management method option syntax now supports the
> > > > NOT_EQUALS
> > > > >> > > operator for greater flexibility with filtering results of
> > > > management
> > > > >> > > operations.
> > > > >> > > - Configuration for diverts created via management can now be
> > > > >> done via
> > > > >> > > JSON.
> > > > >> > >
> > > > >> > > The release notes can be found here:
> > > > >> > >
> > > > >>
> > > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12355013
> > > > >> > >
> > > > >> > > Ths git commit report is here:
> > > > >> > >
> > > > >>
> > > >
> > > https://activemq.apache.org/components/artemis/download/commit-report-2.38.0
> > > > >> > >
> > > > >> > > Source and binary distributions can be found here:
> > > > >> > >
> > > > >>
> > > > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.38.0/
> > > > >> > >
> > > > >> > > The Maven staging repository is here:
> > > > >> > >
> > > > >>
> > > >
> > > https://repository.apache.org/content/repositories/orgapacheactivemq-1410
> > > > >> > >
> > > > >> > > 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 <version>
> > > > >> > >
> > > > >> > > [ ] +1 approve this release
> > > > >> > > [ ] +0 no opinion
> > > > >> > > [ ] -1 disapprove (and reason why)
> > > > >> > >
> > > > >> > > Here's my +1
> > > > >> > >
> > > > >> > >
> > > > >> > > Justin
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > > > >> For additional commands, e-mail: dev-help@activemq.apache.org
> > > > >> For further information, visit: https://activemq.apache.org/contact
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [CANCEL][VOTE] Apache ActiveMQ Artemis 2.38.0
Posted by Robbie Gemmell <ro...@gmail.com>.
Well, crap...I just added a whole section about the reproducibility
checks before seeing this, and hadn't noticed your other PR. I'll
review the PR and perhaps revert my change, merge, and then redo it.
On Mon, 21 Oct 2024 at 22:03, Justin Bertram <jb...@apache.org> wrote:
>
> I plan on adding steps to the release documentation to mitigate this in the
> future including how to verify reproducibility.
>
> At the moment I already have a PR [1] for other, unrelated updates to the
> release doc that I'd like to get merged first, though.
>
>
> Justin
>
> [1] https://github.com/apache/activemq-artemis/pull/5304
>
> On Mon, Oct 21, 2024 at 3:59 PM Clebert Suconic <cl...@gmail.com>
> wrote:
>
> > I don't understand how to avoid this in the future... and how to check it?
> > I think we should update the RELEASE.md with steps to verify and avoid it
> > but I don't understand it 100%.. just that something got the wrong mask on
> > Justin's env causing a reproducing issue.
> >
> > Clebert Suconic
> >
> >
> > On Mon, Oct 21, 2024 at 3:05 PM Justin Bertram <jb...@apache.org>
> > wrote:
> >
> > > I'm cancelling this vote due to the build-reproducibility issue that
> > Robbie
> > > outlined.
> > >
> > >
> > > Justin
> > >
> > > On Mon, Oct 21, 2024 at 1:58 PM Justin Bertram <jb...@apache.org>
> > > wrote:
> > >
> > > > For the sake of clarity and consistency I'm going to cancel this vote,
> > > > re-spin to fix the build-repeatability issue, and send another vote.
> > > >
> > > > Thanks for testing this, Robbie!
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Mon, Oct 21, 2024 at 9:39 AM Robbie Gemmell <
> > robbie.gemmell@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> As an explainer, the cause for the reproducibility check failing looks
> > > >> to be from a difference in umask between Justin's env and those used
> > > >> for previous releases and in turn the Reproducible Central buildspec
> > > >> used to verify the reproducibility.
> > > >>
> > > >> On previous systems that did the release, a umask of [0]022 was in
> > > >> effect. On Justins, a umask of [0]002 was in effect. When I changed
> > > >> umask to [0]002 I was then able to do a 100% reproduction of the
> > > >> build.
> > > >>
> > > >> I'm not yet clear on why, but for the 3 war files in the build, the
> > > >> permissions on the embedded maven detail files (but none of the actual
> > > >> content files) are influenced by the umask:
> > > >> META-INF/maven/<groupId>/<artifact-id>/pom.xml
> > > >> META-INF/maven/<groupId>/<artifact-id>/pom.properties
> > > >>
> > > >> The war files contents then in turn influence the binary assembly and
> > > >> related checksum files, giving a total of 7 differences in the overall
> > > >> build. None of the 'actual content' differs as such, just the
> > > >> permissions, the metadata for which throws off the overall assembly.
> > > >>
> > > >> The same type of generated files are also embedded in all the jar
> > > >> files, but are not influenced by the differing umasks so the jars all
> > > >> came out the same regardless.
> > > >>
> > > >> We could either proceed and try to update the buildspec at
> > > >> Reproducible Central to compensate (and then need to update it again
> > > >> to switch back in future if we make things consistent). Or we could
> > > >> redeploy the build to make this consistent with prior releases, the
> > > >> binary assembly and sig+checksum would get updated, as would the sig
> > > >> for the source release (embedded timestamp) though not the source
> > > >> archive itself.
> > > >>
> > > >> Thoughts, Justin?
> > > >>
> > > >> On Fri, 18 Oct 2024 at 17:26, Robbie Gemmell <
> > robbie.gemmell@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > -1, for now at least.
> > > >> >
> > > >> > The deployed convenience binaries failed a reproducibility check,
> > even
> > > >> > though all the sub-content in them ultimately seems to be the same
> > as
> > > >> > in the rebuild. A permissions difference in a few modules (the 3
> > > >> > console war files) META-INF files seems to be the cause, which in
> > turn
> > > >> > rippled through to the binary assembly archives as a whole.
> > > >> >
> > > >> > I'd like to try some redeployments on Monday to see whether we could
> > > >> > resolve the issue, or at least isolate a reason/env-difference that
> > > >> > prompts it.
> > > >> >
> > > >> > Note -1's are not a veto on releases, and even with my -1 it still
> > > >> > meets the criteria necessary to proceed, i.e can currently still be
> > > >> > released as-is if so desired.
> > > >> >
> > > >> > I checked things over as follows:
> > > >> > - Verified the signature + checksum files.
> > > >> > - Checked for LICENCE + NOTICE files in the archives.
> > > >> > - Checked licence headers in the source archive by running:
> > > >> > "mvn apache-rat:check"
> > > >> > - Ran the Qpid JMS 2.6.1 HelloWorld against a broker from the binary
> > > >> > archive on JDK 17.
> > > >> > - Ran the source build and the AMQP integration tests on JDK 17
> > with:
> > > >> > "mvn clean install -DskipTests && cd tests/integration-tests/ &&
> > mvn
> > > >> > -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
> > > >> > test"
> > > >> > - Verified the build reproducibility using the tooling at
> > Reproducible
> > > >> > Central, which failed as per above.
> > > >> >
> > > >> > Robbie
> > > >> >
> > > >> > On Wed, 16 Oct 2024 at 17:13, Justin Bertram <jb...@apache.org>
> > > >> wrote:
> > > >> > >
> > > >> > > I would like to propose an Apache ActiveMQ Artemis 2.38.0 release.
> > > >> > >
> > > >> > > Highlights include:
> > > >> > >
> > > >> > > - WebSocket compression is now supported. This compression can be
> > > used
> > > >> > > transparently for AMQP, STOMP, or MQTT when communication is over
> > > >> > > WebSockets.
> > > >> > > - The ActiveMQServerMessagePlugin now has a messageMoved()
> > callback.
> > > >> > > - Core bridge configuration now supports client-id which will make
> > > it
> > > >> much
> > > >> > > easier to identify bridge connections on remote brokers.
> > > >> > > - The consumer CLI command now supports consuming messages
> > > "forever."
> > > >> > > - The authentication & authorization caches now have detailed
> > debug
> > > >> logging.
> > > >> > > - There’s been a handful of updates to broker management
> > including:
> > > >> > > - The documentation has been improved with more examples for
> > > >> Jolokia
> > > >> > > and a new sub-section on management method option syntax.
> > > >> > > - It’s now possible to pass empty "options" to the management
> > > >> methods
> > > >> > > that accept them.
> > > >> > > - The management methods which return paged results can now
> > > >> return all
> > > >> > > the results together by specifying -1 for either the page or the
> > > >> pageSize.
> > > >> > > - The management method option syntax now supports the
> > > NOT_EQUALS
> > > >> > > operator for greater flexibility with filtering results of
> > > management
> > > >> > > operations.
> > > >> > > - Configuration for diverts created via management can now be
> > > >> done via
> > > >> > > JSON.
> > > >> > >
> > > >> > > The release notes can be found here:
> > > >> > >
> > > >>
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12355013
> > > >> > >
> > > >> > > Ths git commit report is here:
> > > >> > >
> > > >>
> > >
> > https://activemq.apache.org/components/artemis/download/commit-report-2.38.0
> > > >> > >
> > > >> > > Source and binary distributions can be found here:
> > > >> > >
> > > >>
> > > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.38.0/
> > > >> > >
> > > >> > > The Maven staging repository is here:
> > > >> > >
> > > >>
> > >
> > https://repository.apache.org/content/repositories/orgapacheactivemq-1410
> > > >> > >
> > > >> > > 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 <version>
> > > >> > >
> > > >> > > [ ] +1 approve this release
> > > >> > > [ ] +0 no opinion
> > > >> > > [ ] -1 disapprove (and reason why)
> > > >> > >
> > > >> > > Here's my +1
> > > >> > >
> > > >> > >
> > > >> > > Justin
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > > >> For additional commands, e-mail: dev-help@activemq.apache.org
> > > >> For further information, visit: https://activemq.apache.org/contact
> > > >>
> > > >>
> > > >>
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [CANCEL][VOTE] Apache ActiveMQ Artemis 2.38.0
Posted by Justin Bertram <jb...@apache.org>.
I plan on adding steps to the release documentation to mitigate this in the
future including how to verify reproducibility.
At the moment I already have a PR [1] for other, unrelated updates to the
release doc that I'd like to get merged first, though.
Justin
[1] https://github.com/apache/activemq-artemis/pull/5304
On Mon, Oct 21, 2024 at 3:59 PM Clebert Suconic <cl...@gmail.com>
wrote:
> I don't understand how to avoid this in the future... and how to check it?
> I think we should update the RELEASE.md with steps to verify and avoid it
> but I don't understand it 100%.. just that something got the wrong mask on
> Justin's env causing a reproducing issue.
>
> Clebert Suconic
>
>
> On Mon, Oct 21, 2024 at 3:05 PM Justin Bertram <jb...@apache.org>
> wrote:
>
> > I'm cancelling this vote due to the build-reproducibility issue that
> Robbie
> > outlined.
> >
> >
> > Justin
> >
> > On Mon, Oct 21, 2024 at 1:58 PM Justin Bertram <jb...@apache.org>
> > wrote:
> >
> > > For the sake of clarity and consistency I'm going to cancel this vote,
> > > re-spin to fix the build-repeatability issue, and send another vote.
> > >
> > > Thanks for testing this, Robbie!
> > >
> > >
> > > Justin
> > >
> > > On Mon, Oct 21, 2024 at 9:39 AM Robbie Gemmell <
> robbie.gemmell@gmail.com
> > >
> > > wrote:
> > >
> > >> As an explainer, the cause for the reproducibility check failing looks
> > >> to be from a difference in umask between Justin's env and those used
> > >> for previous releases and in turn the Reproducible Central buildspec
> > >> used to verify the reproducibility.
> > >>
> > >> On previous systems that did the release, a umask of [0]022 was in
> > >> effect. On Justins, a umask of [0]002 was in effect. When I changed
> > >> umask to [0]002 I was then able to do a 100% reproduction of the
> > >> build.
> > >>
> > >> I'm not yet clear on why, but for the 3 war files in the build, the
> > >> permissions on the embedded maven detail files (but none of the actual
> > >> content files) are influenced by the umask:
> > >> META-INF/maven/<groupId>/<artifact-id>/pom.xml
> > >> META-INF/maven/<groupId>/<artifact-id>/pom.properties
> > >>
> > >> The war files contents then in turn influence the binary assembly and
> > >> related checksum files, giving a total of 7 differences in the overall
> > >> build. None of the 'actual content' differs as such, just the
> > >> permissions, the metadata for which throws off the overall assembly.
> > >>
> > >> The same type of generated files are also embedded in all the jar
> > >> files, but are not influenced by the differing umasks so the jars all
> > >> came out the same regardless.
> > >>
> > >> We could either proceed and try to update the buildspec at
> > >> Reproducible Central to compensate (and then need to update it again
> > >> to switch back in future if we make things consistent). Or we could
> > >> redeploy the build to make this consistent with prior releases, the
> > >> binary assembly and sig+checksum would get updated, as would the sig
> > >> for the source release (embedded timestamp) though not the source
> > >> archive itself.
> > >>
> > >> Thoughts, Justin?
> > >>
> > >> On Fri, 18 Oct 2024 at 17:26, Robbie Gemmell <
> robbie.gemmell@gmail.com>
> > >> wrote:
> > >> >
> > >> > -1, for now at least.
> > >> >
> > >> > The deployed convenience binaries failed a reproducibility check,
> even
> > >> > though all the sub-content in them ultimately seems to be the same
> as
> > >> > in the rebuild. A permissions difference in a few modules (the 3
> > >> > console war files) META-INF files seems to be the cause, which in
> turn
> > >> > rippled through to the binary assembly archives as a whole.
> > >> >
> > >> > I'd like to try some redeployments on Monday to see whether we could
> > >> > resolve the issue, or at least isolate a reason/env-difference that
> > >> > prompts it.
> > >> >
> > >> > Note -1's are not a veto on releases, and even with my -1 it still
> > >> > meets the criteria necessary to proceed, i.e can currently still be
> > >> > released as-is if so desired.
> > >> >
> > >> > I checked things over as follows:
> > >> > - Verified the signature + checksum files.
> > >> > - Checked for LICENCE + NOTICE files in the archives.
> > >> > - Checked licence headers in the source archive by running:
> > >> > "mvn apache-rat:check"
> > >> > - Ran the Qpid JMS 2.6.1 HelloWorld against a broker from the binary
> > >> > archive on JDK 17.
> > >> > - Ran the source build and the AMQP integration tests on JDK 17
> with:
> > >> > "mvn clean install -DskipTests && cd tests/integration-tests/ &&
> mvn
> > >> > -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
> > >> > test"
> > >> > - Verified the build reproducibility using the tooling at
> Reproducible
> > >> > Central, which failed as per above.
> > >> >
> > >> > Robbie
> > >> >
> > >> > On Wed, 16 Oct 2024 at 17:13, Justin Bertram <jb...@apache.org>
> > >> wrote:
> > >> > >
> > >> > > I would like to propose an Apache ActiveMQ Artemis 2.38.0 release.
> > >> > >
> > >> > > Highlights include:
> > >> > >
> > >> > > - WebSocket compression is now supported. This compression can be
> > used
> > >> > > transparently for AMQP, STOMP, or MQTT when communication is over
> > >> > > WebSockets.
> > >> > > - The ActiveMQServerMessagePlugin now has a messageMoved()
> callback.
> > >> > > - Core bridge configuration now supports client-id which will make
> > it
> > >> much
> > >> > > easier to identify bridge connections on remote brokers.
> > >> > > - The consumer CLI command now supports consuming messages
> > "forever."
> > >> > > - The authentication & authorization caches now have detailed
> debug
> > >> logging.
> > >> > > - There’s been a handful of updates to broker management
> including:
> > >> > > - The documentation has been improved with more examples for
> > >> Jolokia
> > >> > > and a new sub-section on management method option syntax.
> > >> > > - It’s now possible to pass empty "options" to the management
> > >> methods
> > >> > > that accept them.
> > >> > > - The management methods which return paged results can now
> > >> return all
> > >> > > the results together by specifying -1 for either the page or the
> > >> pageSize.
> > >> > > - The management method option syntax now supports the
> > NOT_EQUALS
> > >> > > operator for greater flexibility with filtering results of
> > management
> > >> > > operations.
> > >> > > - Configuration for diverts created via management can now be
> > >> done via
> > >> > > JSON.
> > >> > >
> > >> > > The release notes can be found here:
> > >> > >
> > >>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12355013
> > >> > >
> > >> > > Ths git commit report is here:
> > >> > >
> > >>
> >
> https://activemq.apache.org/components/artemis/download/commit-report-2.38.0
> > >> > >
> > >> > > Source and binary distributions can be found here:
> > >> > >
> > >>
> > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.38.0/
> > >> > >
> > >> > > The Maven staging repository is here:
> > >> > >
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheactivemq-1410
> > >> > >
> > >> > > 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 <version>
> > >> > >
> > >> > > [ ] +1 approve this release
> > >> > > [ ] +0 no opinion
> > >> > > [ ] -1 disapprove (and reason why)
> > >> > >
> > >> > > Here's my +1
> > >> > >
> > >> > >
> > >> > > Justin
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > >> For additional commands, e-mail: dev-help@activemq.apache.org
> > >> For further information, visit: https://activemq.apache.org/contact
> > >>
> > >>
> > >>
> >
>
Re: [CANCEL][VOTE] Apache ActiveMQ Artemis 2.38.0
Posted by Clebert Suconic <cl...@gmail.com>.
I don't understand how to avoid this in the future... and how to check it?
I think we should update the RELEASE.md with steps to verify and avoid it
but I don't understand it 100%.. just that something got the wrong mask on
Justin's env causing a reproducing issue.
Clebert Suconic
On Mon, Oct 21, 2024 at 3:05 PM Justin Bertram <jb...@apache.org> wrote:
> I'm cancelling this vote due to the build-reproducibility issue that Robbie
> outlined.
>
>
> Justin
>
> On Mon, Oct 21, 2024 at 1:58 PM Justin Bertram <jb...@apache.org>
> wrote:
>
> > For the sake of clarity and consistency I'm going to cancel this vote,
> > re-spin to fix the build-repeatability issue, and send another vote.
> >
> > Thanks for testing this, Robbie!
> >
> >
> > Justin
> >
> > On Mon, Oct 21, 2024 at 9:39 AM Robbie Gemmell <robbie.gemmell@gmail.com
> >
> > wrote:
> >
> >> As an explainer, the cause for the reproducibility check failing looks
> >> to be from a difference in umask between Justin's env and those used
> >> for previous releases and in turn the Reproducible Central buildspec
> >> used to verify the reproducibility.
> >>
> >> On previous systems that did the release, a umask of [0]022 was in
> >> effect. On Justins, a umask of [0]002 was in effect. When I changed
> >> umask to [0]002 I was then able to do a 100% reproduction of the
> >> build.
> >>
> >> I'm not yet clear on why, but for the 3 war files in the build, the
> >> permissions on the embedded maven detail files (but none of the actual
> >> content files) are influenced by the umask:
> >> META-INF/maven/<groupId>/<artifact-id>/pom.xml
> >> META-INF/maven/<groupId>/<artifact-id>/pom.properties
> >>
> >> The war files contents then in turn influence the binary assembly and
> >> related checksum files, giving a total of 7 differences in the overall
> >> build. None of the 'actual content' differs as such, just the
> >> permissions, the metadata for which throws off the overall assembly.
> >>
> >> The same type of generated files are also embedded in all the jar
> >> files, but are not influenced by the differing umasks so the jars all
> >> came out the same regardless.
> >>
> >> We could either proceed and try to update the buildspec at
> >> Reproducible Central to compensate (and then need to update it again
> >> to switch back in future if we make things consistent). Or we could
> >> redeploy the build to make this consistent with prior releases, the
> >> binary assembly and sig+checksum would get updated, as would the sig
> >> for the source release (embedded timestamp) though not the source
> >> archive itself.
> >>
> >> Thoughts, Justin?
> >>
> >> On Fri, 18 Oct 2024 at 17:26, Robbie Gemmell <ro...@gmail.com>
> >> wrote:
> >> >
> >> > -1, for now at least.
> >> >
> >> > The deployed convenience binaries failed a reproducibility check, even
> >> > though all the sub-content in them ultimately seems to be the same as
> >> > in the rebuild. A permissions difference in a few modules (the 3
> >> > console war files) META-INF files seems to be the cause, which in turn
> >> > rippled through to the binary assembly archives as a whole.
> >> >
> >> > I'd like to try some redeployments on Monday to see whether we could
> >> > resolve the issue, or at least isolate a reason/env-difference that
> >> > prompts it.
> >> >
> >> > Note -1's are not a veto on releases, and even with my -1 it still
> >> > meets the criteria necessary to proceed, i.e can currently still be
> >> > released as-is if so desired.
> >> >
> >> > I checked things over as follows:
> >> > - Verified the signature + checksum files.
> >> > - Checked for LICENCE + NOTICE files in the archives.
> >> > - Checked licence headers in the source archive by running:
> >> > "mvn apache-rat:check"
> >> > - Ran the Qpid JMS 2.6.1 HelloWorld against a broker from the binary
> >> > archive on JDK 17.
> >> > - Ran the source build and the AMQP integration tests on JDK 17 with:
> >> > "mvn clean install -DskipTests && cd tests/integration-tests/ && mvn
> >> > -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.**
> >> > test"
> >> > - Verified the build reproducibility using the tooling at Reproducible
> >> > Central, which failed as per above.
> >> >
> >> > Robbie
> >> >
> >> > On Wed, 16 Oct 2024 at 17:13, Justin Bertram <jb...@apache.org>
> >> wrote:
> >> > >
> >> > > I would like to propose an Apache ActiveMQ Artemis 2.38.0 release.
> >> > >
> >> > > Highlights include:
> >> > >
> >> > > - WebSocket compression is now supported. This compression can be
> used
> >> > > transparently for AMQP, STOMP, or MQTT when communication is over
> >> > > WebSockets.
> >> > > - The ActiveMQServerMessagePlugin now has a messageMoved() callback.
> >> > > - Core bridge configuration now supports client-id which will make
> it
> >> much
> >> > > easier to identify bridge connections on remote brokers.
> >> > > - The consumer CLI command now supports consuming messages
> "forever."
> >> > > - The authentication & authorization caches now have detailed debug
> >> logging.
> >> > > - There’s been a handful of updates to broker management including:
> >> > > - The documentation has been improved with more examples for
> >> Jolokia
> >> > > and a new sub-section on management method option syntax.
> >> > > - It’s now possible to pass empty "options" to the management
> >> methods
> >> > > that accept them.
> >> > > - The management methods which return paged results can now
> >> return all
> >> > > the results together by specifying -1 for either the page or the
> >> pageSize.
> >> > > - The management method option syntax now supports the
> NOT_EQUALS
> >> > > operator for greater flexibility with filtering results of
> management
> >> > > operations.
> >> > > - Configuration for diverts created via management can now be
> >> done via
> >> > > JSON.
> >> > >
> >> > > The release notes can be found here:
> >> > >
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12355013
> >> > >
> >> > > Ths git commit report is here:
> >> > >
> >>
> https://activemq.apache.org/components/artemis/download/commit-report-2.38.0
> >> > >
> >> > > Source and binary distributions can be found here:
> >> > >
> >>
> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.38.0/
> >> > >
> >> > > The Maven staging repository is here:
> >> > >
> >>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1410
> >> > >
> >> > > 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 <version>
> >> > >
> >> > > [ ] +1 approve this release
> >> > > [ ] +0 no opinion
> >> > > [ ] -1 disapprove (and reason why)
> >> > >
> >> > > Here's my +1
> >> > >
> >> > >
> >> > > Justin
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> >> For additional commands, e-mail: dev-help@activemq.apache.org
> >> For further information, visit: https://activemq.apache.org/contact
> >>
> >>
> >>
>