Wednesday, 27 May 2020

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

No comments:

Post a comment