Traffic Parrot 5.12.0 released, whats new?

We have just released version 5.12.0. Here is a list of the changes that came with the release:

Features

• New property that allows configuring how IBM® MQ queues will be accessed

  trafficparrot.ibmmq.connect.options.accessQueue.output=MQOO_OUTPUT|MQOO_FAIL_IF_QUIESCING

• New property that allows skipping logging message body for native IBM® MQ

  trafficparrot.ibmmq.logger.logMessageBody=true

• Native IBM® MQ now respects the existing properties that allow for caching mappings in memory

  trafficparrot.virtualservice.mapping.cache.milliseconds=0
  trafficparrot.virtualservice.mapping.cache.populate.on.startup=false

• You can now configure per connection to an IBM® MQ broker how many read and how many write connections to open. You do it in the ibm-mq-connections.json. For example:

  "readConnectionsToOpen": 5,
  "writeConnectionsToOpen": 5

• The Native IBM® MQ mapping allows for configuring how many threads should be used to access the queue, for example:

  "receiveThreads" : 5,
  "sendThreads" : 1

• You can define in the mapping how many messages the Native IBM® MQ connector will be keeping in memory at once, which will be relevant for scenarios when sending delayd messages, for example:

  "maxMessagesInProgress": 1000000

• You can start the Native IBM® MQ replay with a script, for example:

  #
  # This is a sample comment 1
  #
  RequestQueueManager:'Request QM1'
  ResponseQueueManager:'Response QM1'
  RequestQueueNames:'REQ_1_A','REQ_1_B'
  
  #
  # This is a sample comment 2
  #
  RequestQueueManager:'Request QM2'
  ResponseQueueManager:'Response QM2'
  RequestQueueNames:'REQ_2_A','REQ_2_B'

• Handlebar templates are cached allowing for better performance

Changes

• There has been performance improvements made to the Native IBM® MQ connector. See the performance benchmarks for more details.
• Native IBM® MQ response messages during a replay have the replyToQueueEmpty and replyToQueueManager set to the connected queue manager if they did not have any of these attributes set on the request message
• Native IBM® MQ sends the queue manager name along with queue name when sending a message. This is applicable in scenarios with multiple queue managers set up in a cluster without the cluster sender and cluster receiver channels
• Logging more runtime information on startup
• Additional logging when connections to IBM® MQ fail