activemq max-redelivery-delay
by Robert Palm
Dear Brian & team,
have an issue with
/subsystem=messaging-activemq/server=default/address-setting
redelivery-delay is not properly initalized any longer.
Needed to add max-redelivery-delay attrribute to work around.
Was pointed to wildfly , c.f.
---------------------------------------------------------------------------------------
Hi Robert,
the code related to the redelivery-delay is the same in Apache ActiveMQ
Artemis 2.10.1 and 2.37.0 versions. This issue could be caused
by WFLY-19072[1], it sets the MaxRedeliveryDelay default value on the root
of AddressSettings to 0, see
https://github.com/wildfly/wildfly/commit/adf1c4eb41e1ebd69119fea9305ebfe...
[1] https://issues.redhat.com/browse/WFLY-19072
Regards,
Domenico
---------------------------------------------------------------------------------------
Thanks,
-Robert
2 months
WildFly Technology Interest Survey
by Brian Stansberry
If you have 10-15 minutes for an anonymous survey, we'd love to get your
responses to the WildFly Technology Interest Survey!
https://forms.gle/heh23E6kvSmAJnR97
There have been lots of changes over the last few years in the standards
like Jakarta EE and MicroProfile that WildFly implements, and those standard
s will continue to evolve. And of course there are lots of technologies
that WildFly provides or could provide. We'd love to know more about what
technologies you're using or would like to use with WildFly. So, please
take this chance to let us know what's important to you!
Thanks and best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2 months, 1 week
Location of build, dist, ee-build, ee-dist modules
by Brian Stansberry
I'm curious what impact it would have on people if the build and dist
modules were moved under galleon-pack and the ee-build and ee-dist modules
were moved under ee-galleon-pack.
Internal to the WF build any other modules that look for those locations
should be relying on a maven property, so in theory it could be easy to
tweak that property. But there might be a problem with other automation
external to the build (e.g. github actions) that make assumptions about the
location of those modules.
I'm asking this as part of some brainstorming about how to organize the
code base to better reflect the different variants of WF we produce.
Currently the build and dist for WFP are located under the same dir
'preview' as the bits that produce the WFP feature pack and channel. Unlike
the various modules that produce java artifacts (e.g. subsystems), the dist
modules are tightly bound to the FP that produces them, so grouping them
makes some sense.
NBD; I'm just brainstorming.
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2 months, 1 week
