Changes for page 56

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-60
	1	+58

Content

...	...	@@ -1,14 +1,52 @@
1		-Small update that fixes three specific issues.
	1	+Update that improves the AMQP and MQTT messaging capabilities.
2	2
3	3	Find out more in our [release blog]
4	4
5	5
6		-===== Bug Fixes =====
	6	+===== New Features =====
7	7
8		-* Build number 59 broke the debugger, build number 60 fixes this.
9		-* Fixed Kafka components not being able to use key- or truststores from the "resources" tab.
10		-* Deploying flows containing a 'Jetty server' support object in build number 59 only worked on the latest runtime version: build number 60 fixes the backwards compatibility with older runtimes. Note that it is still strongly recommended to update to the latest version of the runtime (5.0.4) if you haven't done so already, because this contains fixes for the Log4j security vulnerability.
	8	+* With this update, eMagiz runtimes can fulfil the role of an MQTT broker. To do this, put an Artemis server support object in your connector and make sure it accepts MQTT protocol communication over web sockets. Internally, handling these (MQTT) messages is no different from handling "normal" (AMQP) messages.
	9	+* Updated Artemis, Qpid, Proton-J and Netty to the latest maintenance releases. These updates mostly contain bugfixes, improvements and performance wins.
11	11
12	12	===== Minor Changes =====
13	13
14		-* Change of behaviour when incoming HTTP headers are mapped to message headers: Up to build 58 the values of incoming HTTP headers were only mapped to an array when it contained multiple values, otherwise the first (and only) value was automatically extracted and used for the message header. Since build 59 the values are always mapped to an array. While this makes the data type of the header more predictable - it is no longer dependent on the number of values a client was sending - it does mean that your SpEL expressions that were previously expecting single values need to now handle array values. In many cases this can be as simple as extracting the first array value like this: "headers.myHeader[0]".
	13	+* Added bundle 'com.emagiz.bundles.artemis-quorum-api' 2.19.0.1
	14	+* Added bundle 'com.emagiz.bundles.netty-handler-proxy' 4.1.70.1
	15	+* Added bundle 'com.emagiz.bundles.netty-transport-classes-epoll' 4.1.70.1
	16	+* Added bundle 'com.emagiz.bundles.netty-transport-classes-kqueue' 4.1.70.1
	17	+* Updated bundle 'com.emagiz.bundles.artemis-server-osgi' from 2.7.0.2 to 2.19.0.1
	18	+* Updated bundle 'com.emagiz.bundles.netty-buffer' from 4.1.50.1 to 4.1.70.1
	19	+* Updated bundle 'com.emagiz.bundles.netty-codec' from 4.1.50.1 to 4.1.70.1
	20	+* Updated bundle 'com.emagiz.bundles.netty-codec-http' from 4.1.50.1 to 4.1.70.1
	21	+* Updated bundle 'com.emagiz.bundles.netty-codec-mqtt' from 4.1.50.1 to 4.1.70.1
	22	+* Updated bundle 'com.emagiz.bundles.netty-codec-socks' from 4.1.50.1 to 4.1.70.1
	23	+* Updated bundle 'com.emagiz.bundles.netty-common' from 4.1.50.1 to 4.1.70.1
	24	+* Updated bundle 'com.emagiz.bundles.netty-handler' from 4.1.50.1 to 4.1.70.1
	25	+* Updated bundle 'com.emagiz.bundles.netty-resolver' from 4.1.50.1 to 4.1.70.1
	26	+* Updated bundle 'com.emagiz.bundles.netty-transport' from 4.1.50.1 to 4.1.70.1
	27	+* Updated bundle 'com.emagiz.bundles.netty-transport-native-epoll' from 4.1.50.1 to 4.1.70.1
	28	+* Updated bundle 'com.emagiz.bundles.netty-transport-native-kqueue' from 4.1.50.1 to 4.1.70.1
	29	+* Updated bundle 'com.emagiz.bundles.netty-transport-native-unix-common' from 4.1.50.1 to 4.1.70.1
	30	+* Updated bundle 'com.emagiz.bundles.proton-j' from 0.33.5.1 to 0.33.10.1
	31	+* Updated bundle 'com.emagiz.bundles.qpid-jms-client' from 0.48.0.1 to 0.59.0.1
	32	+* Updated bundle 'com.emagiz.components.artemis' from 2.0.0 to 2.0.1
	33	+* Updated bundle 'com.emagiz.components.qpid' from 2.0.0 to 2.0.1
	34	+* Replaced bundle 'org.apache.activemq.artemis-amqp-protocol' 2.7.0 with 'com.emagiz.bundles.activemq-artemis-native' 2.19.0.1
	35	+* Replaced bundle 'org.apache.activemq.artemis-hornetq-protocol' 2.7.0 with 'com.emagiz.bundles.artemis-hornetq-protocol' 2.19.0.1
	36	+* Replaced bundle 'org.apache.activemq.artemis-hqclient-protocol' 2.7.0 with 'com.emagiz.bundles.artemis-hqclient-protocol' 2.19.0.1
	37	+* Replaced bundle 'org.apache.activemq.artemis-mqtt-protocol' 2.7.0 with 'com.emagiz.bundles.artemis-mqtt-protocol' 2.19.0.1
	38	+* Replaced bundle 'org.apache.activemq.artemis-native' 1.0.0 with 'com.emagiz.bundles.activemq-artemis-native' 1.0.2.1
	39	+* Replaced bundle 'org.apache.activemq.artemis-stomp-protocol' 2.7.0 with 'com.emagiz.bundles.artemis-stomp-protocol' 2.19.0.1
	40	+* Replaced bundle 'org.apache.johnzon.core' 0.9.5 with 'com.emagiz.bundles.johnzon-core' 1.2.15.1
	41	+
	42	+===== Known Issues =====
	43	+
	44	+* Retrying to deliver a message from the dead-letter queue does not work, breaking the message redelivery feature. This is fixed in build 59.
	45	+
	46	+===== Remarks =====
	47	+
	48	+* When upgrading a JMS server flow, the persisted messages stored in the Artemis server are automatically migrated from version 2.7.0 to 2.19.0 to guarantee a smooth upgrade process without any message loss. However, this migration process is irreversible, meaning that if for any reason you want to "downgrade" from 2.19.0 to 2.7.0 you must first use the "clean store" functionality in the deploy phase (cloud) or manually empty the Artemis 'data' directory (on-premises).
	49	+* Because of the above, if you are upgrading a failover setup (double lane), make sure to do the upgrade in the correct order for the live and backup JMS servers:
	50	+ ** Install the new build number (58) on both the live and backup servers.
	51	+ ** Start the new flow on the backup server first, and when that has finished start the new flow on the live server. This step automatically migrates everything in the Artemis 'data' directory (see above).
	52	+ ** When everything runs correctly again, uninstall the old flow from the backup server first and then uninstall it from the live server. While uninstalling you might notice some disruptions in the log: this is expected and should only last for a few seconds.