Can I use Traffic Parrot over VPN?

"Our offshore developers will be using Traffic Parrot. Can you please clarify how that will impact the number of parallel licenses used? If a VPN connection is terminated, the license should stop being used?" - Software Developer working for a global financial institution.

We understand you wanted to know if a Traffic Parrot (TP) license will be checked back into the licensing server pool if the connection is dropped (for example when a VPN connection is closed).

The answer is yes. If the person was running TP outside via VPN connection and the discontinued VPN connection results in the lack of connectivity to the licensing server, the TP license server will recognise a timeout and will check back the license into the pool after the configurable timeout passes. The TP instance without the connection will shut down and the developer will not be able to use it.

If however, the developer was using VPN to access a development machine inside the organization then the connection would not be terminated, and the TP license would be still checked out by the TP instance running on the VM.

Please find the sample diagrams below. 

Traffic Parrot 5.22.0 released, what's new?

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

Features

• Made mapping name editable in the UI for all mapping types

Fixes

• Ensure internal server errors log the full stack trace

Changes

• Native IBM® MQ connections will now warn once in the logs the first time that a connection is shared between multiple threads, which can degrade performance. The mapping fields receiveThreads and sendThreads control the number of threads per queue. The ibm-mq-connections.json configuration controls the total readConnectionsToOpen and writeConnectionsToOpen per queue manager.

Traffic Parrot 5.21.6 released, what's new?

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

Features

• New property trafficparrot.virtualservice.http.monitorPerformance can be used to enable HTTP response timings in the logs:

  2020-10-07 20:09:32,330 INFO  Request to 'GET /test123' was received on '2020-10-07T19:09:32.326Z' from '127.0.0.1'. Response was sent on '2020-10-07T19:09:32.397Z' to '127.0.0.1'. Total processing time 71ms

• Added new PassthroughMessage MQ proxy example to the SDK workspace

Fixes

• Fixed support for OpenAPI array examples specified as a comma separated string
• Ensure startup error causes are recorded in the logs

Changes

• Upgraded bundled JRE from 8u262 to 8u265
• Display system tray in a background thread to improve startup times on some systems
• Valid JSON bodies in mapping files will be persisted as inline JSON rather than an escaped string