Overview
What is its Purpose?
What is its Purpose?
Centralized Management
Connection provides reliable access to ActiveMQ brokers, centralizing message sending and receiving operations.
Reusability
Eliminates configuration repetition by providing reusable connection parameters across different Integration Flow steps.
Environment-Based Management
Provides consistent deployment processes between Development, Test, and Production through environment-based management.
Performance and Durability
Provides performance and durability in high-traffic scenarios thanks to advanced timeout and pool management.
Working Principle
Working Principle
Connection Initiation
When a Message Queue connection is requested from within an Integration Flow or Connector, the system reads the configured connection parameters.
Connection Pool Management
Previously opened connections are reused with active connection pool strategy; if pool is full, a new connection is created.
Authentication
Authentication to broker is performed with basic Authentication mechanism (username/password) or optional SSL/TLS certificate verification.
Data Communication
JMS messages are transmitted or consumed synchronously/asynchronously to Queue or Topic targets over AMQP/TCP protocol.
Connection Management
When the operation completes, the connection returns to the pool; passive connections are closed according to pool policies.
Error Management
In case of connection error, timeout, or authentication error, error details are logged, system automatically retries and produces a warning message to the user.
Usage Areas
Usage Areas
Asynchronous Message Queue
Application components executing asynchronous message queue operations via ActiveMQ.
Reliable Message Broadcast
Reliable message broadcast and consumption in Queue or Topic-based integrations.
High Volume Message Scenarios
High volume message scenarios in business intelligence, notification, or integration services.
Inter-Microservice Communication
AMQP-based event sharing in inter-microservice communication.
Legacy JMS Integration
Including legacy JMS applications in modern Integration Flow steps.
Technical Features and Capabilities
Basic Features
Protocol Flexibility: Provides connections suitable for different ActiveMQ distributions with AMQP or TCP protocol selection. Destination Management: Manages Queue or Topic destinations from a single screen, storing them together with necessary credentials. Session Acknowledgement Policy: Fast integration with AUTO_ACKNOWLEDGE default; provides advanced control with CLIENT_ACKNOWLEDGE or TRANSACTED. Environment-Based Configuration: Ability to define separate connection parameters for each environment (Development, Test, Production). Enable/Disable Control: Activating or deactivating the Connection (enable/disable toggle). In passive state, the connection cannot be used but its configuration is preserved.Advanced Features
Timeout Management: Connection, request response, and message sending durations can be precisely adjusted in milliseconds. Content Customization: Message metadata is standardized with Content-Type and Content-Encoding fields. Client ID Definition: Persistent subscription or durable consumer scenarios become possible thanks to JMS ClientID support. Connection Test Feature: Ability to validate connection parameters before saving via “Test Connection” button. Export/Import Feature: Exporting Connection configuration as a ZIP file. Importing to different environments (Development, Test, Production). Version control and backup capability. Connection Monitoring: Monitoring connection health, pool status, and performance metrics.Connection Parameters
Mandatory Parameters
Mandatory Parameters
Name
Description: Connection name (must be unique)
Example Value:
Notes: Should not start with space, special characters should not be used
Example Value:
Production_ActiveMQNotes: Should not start with space, special characters should not be used
Broker URL
Description: ActiveMQ broker access address
Example Value:
Notes: Includes protocol (amqp/tcp) and port value
Example Value:
tcp://mq.prod.local:61616Notes: Includes protocol (amqp/tcp) and port value
Username
Description: ActiveMQ access username
Example Value:
Notes: Authorized account should be used
Example Value:
mq_service_userNotes: Authorized account should be used
Password
Description: Password belonging to the user
Example Value:
Notes: Secret manager should be used for password storage
Example Value:
********Notes: Secret manager should be used for password storage
Destination Type
Description: Queue or Topic selection
Example Value:
Notes: Enum values: QUEUE, TOPIC
Example Value:
QUEUENotes: Enum values: QUEUE, TOPIC
Destination Name
Description: Message queue or topic name
Example Value:
Notes: Should comply with namespace rules
Example Value:
order.events.queueNotes: Should comply with namespace rules
ActiveMQ Connection Protocol Type
Description: Connection protocol to be used
Example Value:
Notes: Enum values: AMQP, TCP
Example Value:
AMQPNotes: Enum values: AMQP, TCP
Session Acknowledgement
Description: JMS session acknowledgement type
Example Value:
Notes: Enum values: AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE, SESSION_TRANSACTED, DUPS_OK_ACKNOWLEDGE
Example Value:
AUTO_ACKNOWLEDGENotes: Enum values: AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE, SESSION_TRANSACTED, DUPS_OK_ACKNOWLEDGE
Environment Id
Description: Environment selection reference
Example Value:
Notes: Environment list comes from Environment service
Example Value:
env-prod-01Notes: Environment list comes from Environment service
Optional Parameters
Optional Parameters
Send Timeout
Description: Wait time for message sending
Default Value: 60000
Recommended Value: 30000 - 120000 range according to need
Default Value: 60000
Recommended Value: 30000 - 120000 range according to need
Request Timeout
Description: Response wait time
Default Value: 60000
Recommended Value: 45000 for critical operations
Default Value: 60000
Recommended Value: 45000 for critical operations
Close Timeout
Description: Connection closing time
Default Value: 60000
Recommended Value: 90000 for long sessions
Default Value: 60000
Recommended Value: 90000 for long sessions
Connect Timeout
Description: Time to connect to broker
Default Value: 60000
Recommended Value: 90000 ms in high latency networks
Default Value: 60000
Recommended Value: 90000 ms in high latency networks
Content Type
Description: Message content type
Default Value: application/json
Recommended Value: application/xml according to workload
Default Value: application/json
Recommended Value: application/xml according to workload
Content Encoding
Description: Message character set
Default Value: UTF-8
Recommended Value: Standard UTF-8 usage is recommended
Default Value: UTF-8
Recommended Value: Standard UTF-8 usage is recommended
Client ID
Description: Persistent subscription identity
Default Value: durable-consumer-1
Recommended Value: Mandatory in durable topic subscriptions
Default Value: durable-consumer-1
Recommended Value: Mandatory in durable topic subscriptions
Timeout and Connection Pool Parameters
Connection Timeout
Description: Maximum wait time for connection establishment
Default: 60000
Min: 1000 | Max: 180000
Unit: milliseconds
Default: 60000
Min: 1000 | Max: 180000
Unit: milliseconds
Request Timeout
Description: Maximum wait time for request response
Default: 60000
Min: 1000 | Max: 180000
Unit: milliseconds
Default: 60000
Min: 1000 | Max: 180000
Unit: milliseconds
Pool Size
Description: Maximum number of connections in Connection pool
Default: 10
Min: 1 | Max: 200
Unit: count
Default: 10
Min: 1 | Max: 200
Unit: count
Send Timeout
Description: Expected longest duration for message sending
Default: 60000
Min: 5000 | Max: 180000
Unit: milliseconds
Default: 60000
Min: 5000 | Max: 180000
Unit: milliseconds
Usage Scenarios
Order Queue Consumption
Situation: New order messages are falling into ActiveMQ queue
Solution: Destination Type=QUEUE, Destination Name=order.events.queue, Protocol=AMQP
Expected Behavior: Integration Flow consumes order messages sequentially
Solution: Destination Type=QUEUE, Destination Name=order.events.queue, Protocol=AMQP
Expected Behavior: Integration Flow consumes order messages sequentially
Live Notification Broadcast
Situation: Websocket notifications will be distributed via topic
Solution: Destination Type=TOPIC, Destination Name=notifications.topic, ClientID=notif-producer
Expected Behavior: All subscribers receive real-time notifications
Solution: Destination Type=TOPIC, Destination Name=notifications.topic, ClientID=notif-producer
Expected Behavior: All subscribers receive real-time notifications
High Security Broker
Situation: Production broker only accepts SSL
Solution: Protocol=TCP, Broker URL=ssl://mq.prod.local:61617, SSL certificate attachments
Expected Behavior: Encrypted connection is successfully established
Solution: Protocol=TCP, Broker URL=ssl://mq.prod.local:61617, SSL certificate attachments
Expected Behavior: Encrypted connection is successfully established
Long Duration Operation
Situation: Batch job is sending large message packages
Solution: Send Timeout=120000, Request Timeout=120000, Pool Size=30
Expected Behavior: Message sending completes without interruption
Solution: Send Timeout=120000, Request Timeout=120000, Pool Size=30
Expected Behavior: Message sending completes without interruption
Test Environment Simulation
Situation: Test broker is low-resource
Solution: Pool Size=5, Request Timeout=45000, Content Type=application/json
Expected Behavior: Resource usage is optimized, test runs stably
Solution: Pool Size=5, Request Timeout=45000, Content Type=application/json
Expected Behavior: Resource usage is optimized, test runs stably
Disaster Recovery
Situation: Need to switch to backup broker
Solution: Broker URL is updated to secondary address, activated with Enable toggle
Expected Behavior: Traffic seamlessly shifts to backup broker
Solution: Broker URL is updated to secondary address, activated with Enable toggle
Expected Behavior: Traffic seamlessly shifts to backup broker
Connection Configuration
Creating New Apache ActiveMQ
Configuration Steps
1
Navigating to Creation Page
- Go to Connection → Apache ActiveMQ section from the left menu.
- Click the [+ Create] button at the top right.
2
Entering Basic Information
Enable Status (Active Status):Set active/passive status with toggle. New connections are active by default.Name (Mandatory):Example:
Production_ActiveMQ- Enter unique name, should not start with space.
- System automatically checks. Green checkmark: available. Red X: existing name.
- Max. 1000 characters.
- Describe the purpose of the connection.
3
Environment Selection
- Select environment from dropdown menu: Development, Test, or Production.
- Different connection parameters can be defined for each environment.
4
ActiveMQ Basic Parameters
- Enter Broker URL, ActiveMQ Connection Protocol Type, Destination Type, Destination Name fields.
- Broker URL should comply with AMQP/TCP schema; destination type should be selected as Queue or Topic.
5
Messaging Session and Content Settings
- Determine Session Acknowledgement type according to your JMS strategy. Optionally fill Content Type, Content Encoding, Client ID fields.
- Client ID is required in durable topic subscriptions.
6
Timeout and Connection Pool Settings
- Enter Send Timeout, Request Timeout, Connect Timeout, Close Timeout values in milliseconds.
- Optimize pool sizes and durations for heavy traffic.
7
Security and Authentication Settings
- Fill Username and Password fields. If SSL/TLS requirements exist, configure broker URL with ssl:// and add necessary certificates to Environment repository.
8
Test Connection
- Click the [Test Connection] button.
- Test whether connection parameters are correct.
- Successful: Green confirmation message, Failed: Error details are shown.
9
Saving
- Click the [Save and Deploy] button at the top right.
- Unique name
- Mandatory fields filled
- Test connection successful (recommended)
- Connection is added to list.
- Becomes available for use in Integration Flow and Connector steps.
- Becomes active according to environment.
Deleting Connection
Deletion Process
- Select Delete from the ⋮ menu at the end of the row.
- Or click the [Delete] button on the connection detail page.
Deletion Tips
Check Before Deleting:
- May be used in Integration Flow or Connector steps.
- Assign an alternative connection if necessary.
- Take backup with Export before deleting.
- Use Disable option instead of deleting.
- Connection becomes passive but is not deleted.
- Can be reactivated when needed.
Exporting/Importing Connection
In this step, users can export (export) existing connections for backup, moving to different environments, or sharing purposes, or import (import) a previously exported connection again. This operation is used to maintain data integrity in version control, transition between test and production environments, or inter-team sharing processes.
Export
Export
Method 1
Select ⋮ → Export from the action menu. ZIP file is automatically downloaded.
Method 2
Click the [Export] button on the connection detail page. ZIP file is downloaded.
File Format
Format:
Example:
{Date}-connection-{ConnectionName}-export.zipExample:
13 Nov 2025-connection-Production_ActiveMQ-export.zipZIP Contents
- Connection JSON file
- Metadata information
- Dependency information (e.g., certificates, key store)
Usage Areas
- Backup
- Moving between environments (Test → Prod)
- Versioning
- Team or project-based sharing
Import
Import
Import Steps
- Click the [Import Apache ActiveMQ] button on the main list.
- Select the downloaded ZIP file.
- System checks: Is format valid? Is there a name conflict? Are dependencies available?
- Then click the [Import] button.
Import Scenarios
Scenario 1: Name Conflict → Overwrite the old connection or create with a new name.Scenario 2: Missing Dependencies → Create missing certificates or key stores first or exclude them during import.
Connection Usage Areas
Creating and Activating Connection
Steps:
- Create the connection.
- Verify the connection with Test Connection.
- Save and activate with Save and Deploy.
- Make sure the connection is in Enabled status.
Usage in Integration / Connector Steps
- Connection is selected in steps that require communication with external systems such as message queue (queue), topic, email, FTP/SFTP, LDAP, or similar.
- Example: Steps like “Send Message”, “Consume Message”, “Upload File”, “Read Directory”.
- Connection selection is made from the Connection field in the configuration of these steps.
Scheduled Job Usage
- In scheduled tasks (e.g., sending messages at certain intervals, file processing, etc.), access to external systems is provided by selecting connection.
- When connection changes, job execution behavior is updated accordingly.
Test Purpose Usage
- Connection correctness can be checked independently from Integration Flow with Connection Test feature.
- This test is critical in the debugging process.
Best Practices
Things to Do and Best Practices
| Category | Description / Recommendations |
|---|---|
| Destination Management | Bad: Routing all workloads to a single queue. Good: Defining separate Queue/Topic for different business types. Best: Using own destination for each business type and documenting naming standards. |
| Protocol Selection | Bad: Using default TCP and ignoring security requirements. Good: Preferring TCP in internal network, AMQP in external network. Best: Providing encrypted communication using SSL/TLS supported AMQP |
| Session Acknowledgement Policy | Bad: Using AUTO_ACKNOWLEDGE in all flows. Good: Switching to CLIENT_ACKNOWLEDGE in critical operations. Best: Using SESSION_TRANSACTED in transactional flows and applying rollback on failure. |
| Credential Management | Bad: Storing username/password as plain text. Good: Masking in configuration file. Best: Retrieving dynamically via Secret Manager or environment variable. |
| Observability | Bad: Not tracking connection logs. Good: Monitoring basic error logs. Best: Sending pool, timeout, and broker metrics to centralized monitoring system. |
| Environment Management | Bad: Using the same connection parameters in all environments. Good: Creating separate connections for each environment. Best: Managing all environments in a single connection using Environment option, only changing environment during inter-environment transitions. |
| Connection Test | Bad: Saving and deploying connection without testing. Good: Verifying with Test Connection before saving. Best: Testing after every parameter change, performing full integration test in test environment before moving to production. |
Security Best Practices
| Security Area | Description / Warnings |
|---|---|
| Broker Access Authorization | Allow only service accounts that need it. Apply role-based policies and remove unnecessary users. |
| Password Management | Periodically renew passwords, use minimum 16 characters, activate audit logs to prevent unauthorized sharing. |
| Durable Subscriber Protection | Keep Client IDs unique, do not use the same identity in multiple applications; otherwise message loss may occur. |
| Credential Management | Store sensitive information such as username and password using environment variable or secret manager. Do not hardcode credentials in code or configuration files. Periodically update passwords. |
| SSL/TLS Usage | Always enable SSL/TLS in Production environment. Use self-signed certificates only in development environment. Track certificate expiration dates and renew on time. |
| Access Control | Allow only authorized users to change Connection configuration. Store connection change logs. Apply change approval process for critical connections. |
Things to Avoid
| Category | Description / Warnings |
|---|---|
| Wrong Destination Name | Why to avoid: Broker target cannot be found, messages are lost. Alternative: Validate destination names in deployment pipeline. |
| Excessive Pool Size | Why to avoid: Resource consumption increases on broker side. Alternative: Determine measured pool sizes according to traffic. |
| Non-Standard Encoding | Why to avoid: Consumers may not be able to decode the message. Alternative: Maintain UTF-8 standard, coordinate if different encoding is needed. |
| Using Production Connection in Test Environment | Why to avoid: Test data can be written to production system, real users can be affected, security risk occurs. Alternative: Create separate connections for each environment, use environment parameter, separate connection names by adding prefix according to environment (Test_, Prod_). |
| Very Low Timeout Values | Why to avoid: Connection constantly times out in network delays, requests fail. Alternative: Adjust timeout values according to real usage scenarios, measure network latency and determine timeouts accordingly. |
| Not Using Connection Pool | Why to avoid: New connection is opened for every request, performance decreases, resource consumption increases, target system load increases. Alternative: Activate connection pool, adjust pool size according to traffic volume, set up pool monitoring. |
Performance Tips
| Criterion | Recommendation / Impact |
|---|---|
| Broker Cluster Integration | Recommendation: Use failover URI structure (failover:(tcp://node1:61616,tcp://node2:61616)). Impact: Automatic reconnection is provided in broker interruptions. |
| Message Throughput | Recommendation: Increase Send Timeout and Pool Size values in high volume sends. Impact: Message queues are consumed without accumulation. |
| Ack Strategy | Recommendation: Provide manual control with CLIENT_ACKNOWLEDGE in critical flows. Impact: Reduces message loss risk. |
| Connection Pool Optimization | Recommendation: Adjust pool size according to peak traffic (recommended: concurrent request count × 1.5), set idle connection timeouts, perform pool health check. Impact: Connection opening cost decreases by 80%, response times decrease, resource usage is optimized. |
| Timeout Values Optimization | Recommendation: Measure real network latency, adjust timeout values accordingly, avoid very low or very high timeouts. Impact: Unnecessary waits are prevented, fast fail-over is provided, user experience improves. |
| Connection Monitoring | Recommendation: Monitor connection pool usage, track timeout rates, perform connection health check, set up alerting. Impact: Problems are detected proactively, performance bottlenecks are identified early, downtime decreases. |
Troubleshooting
| Problem | Possible Causes | Solution Steps |
|---|---|---|
| Cannot Connect to Broker | - Wrong Broker URL - Firewall barrier - Broker service is down | 1. Verify Broker URL and port 2. Test network access (telnet, nc) 3. Check broker logs |
| Destination Not Found | - Queue/topic not created - Wrong name entered - Authorization missing | 1. Verify destination from broker management console 2. Update connection parameter 3. Check user permissions |
| Connection Timeout | - Network delay - Target system responding slowly - Timeout value too low | 1. Check network connectivity 2. Check target system health 3. Increase timeout values 4. Review connection logs |
| Authentication Failed | - Wrong username/password - Expired credentials - Authorization problem | 1. Verify credentials 2. Check that user is active in target system 3. Check that necessary permissions are granted 4. Check SSL/TLS certificates |
| Pool Exhausted | - Pool size too low - Connection leak exists - Traffic too high | 1. Increase pool size 2. Check that connections are properly closed 3. Set idle connection timeouts 4. Monitor connection usage metrics |
| Connection Test Successful But Integration Flow Gives Error | - Different connection may be selected in Integration/Connector step - Step may be misconfigured - Flow/Job may not be redeployed | 1. Check that Connection’s enable toggle is active 2. Verify that correct connection is selected in Integration Flow 3. Redeploy Connection 4. Redeploy Integration Flow or Job 5. Check Gateway logs |
Frequently Asked Questions (FAQ)
| Category | Question | Answer |
|---|---|---|
| General | Can I manage multiple destinations within the same broker with a single connection? | Yes, the same Apache ActiveMQ connection can be used with different destinations in different Integration Flow steps; target destination configuration must be done separately in each step. |
| General | Does message consumption completely stop when connection is disabled? | When disabled, the connection is not reused, integration steps return error or force connection selection. |
| Technical | What settings should I change to switch from AMQP to TCP? | Set ActiveMQ Connection Protocol Type value to TCP, update Broker URL to tcp:// or ssl:// schema, check firewall ports. |
| Technical | How is durable topic subscription activated? | Set Destination Type=TOPIC, enter ClientID field uniquely and enable durable subscriber option on Integration Flow side. |
| Usage | Is automatic retry performed on connection if queue is full? | If broker side returns error, ActiveMQ client retries; still you need to track application logs and do capacity planning. |
| General | Can I use the same connection in multiple Integration Flows? | Yes, the same connection can be used in multiple Integration Flow or Connector steps. This provides centralized management and guarantees configuration consistency. However, changes made to the connection will affect all usage locations, so care should be taken. |
| Technical | Is using connection pool mandatory? | Using connection pool is not mandatory but strongly recommended in high-traffic systems. Reusing existing connections instead of opening new connections for every request significantly improves performance. |
| Usage | Should I create different connections for Test and Production? | Yes, it is recommended to create separate connections for each environment. Alternatively, you can manage all environments within a single connection using the environment parameter. This approach provides easier management and less error risk. |
| Technical | Test Connection is successful but not working in Integration Flow, why? | Several reasons may exist: 1) Connection enable toggle may be passive, 2) A different connection may be selected in Integration step, 3) Connection may not be deployed, 4) Integration Flow may not have been redeployed yet. |
Examples for BROKER URL
AMQP URL Examples
| Scenario | URL Example | Description |
|---|---|---|
| Simple Connection | amqp://localhost:5672 | Most basic AMQP connection |
| Authenticated | amqp://user:password@localhost:5672 | Connection with username and password |
| SSL/TLS | amqps://secure-broker.example.com:5671 | Secure AMQP connection |
| Multiple Brokers | amqp://broker1:5672,amqp://broker2:5672 | Connection to multiple brokers |
| With Timeout Settings | amqp://localhost:5672?transport.connectTimeout=30000&transport.requestTimeout=30000 | Timeout values specified |
| SSL and Failover | amqps://broker:5671?transport.trustStoreLocation=/path/truststore.jks&failover.maxReconnectAttempts=5 | SSL and reconnection settings |
| With Prefetch Settings | amqp://broker:5672?jms.prefetchPolicy.all=1000 | Message prefetch settings |
| Multi-Featured | amqp://broker:5672?jms.prefetchPolicy.all=1000&amqp.idleTimeout=30000&transport.connectTimeout=30000 |
TCP URL Examples
| Scenario | URL Example | Description |
|---|---|---|
| Simple Connection | tcp://localhost:61616 | Most basic TCP connection |
| Authenticated | tcp://user:password@localhost:61616 | Connection with username and password |
| With Timeout Settings | tcp://localhost:61616?soTimeout=30000&soWriteTimeout=30000 | Timeout values specified |
| Simple Failover | failover:(tcp://broker1:61616,tcp://broker2:61616) | Basic failover configuration |
| With SSL | ssl://secure-broker:61617?needClientAuth=true&keyStore=/path/keystore.jks | SSL certificate connection |
| Performance Optimized | tcp://localhost:61616?tcpNoDelay=true&socketBufferSize=65536 | Optimized for performance |
| High Availability | failover:(tcp://primary:61616,tcp://backup:61616)?maxReconnectAttempts=-1 | Configured for high availability |
| Full Failover | failover:(tcp://broker1:61616,tcp://broker2:61616)?initialReconnectDelay=1000&maxReconnectDelay=30000&maxReconnectAttempts=5 | Detailed failover settings |
| Production Environment | failover:(tcp://prod1:61616,tcp://prod2:61616)?randomize=true&priorityBackup=true&useExponentialBackOff=true | Optimized for production environment |
Important Parameters and Values
| Parameter Type | Parameter | Example Value | Description |
|---|---|---|---|
| Timeout | soTimeout | 30000 | Socket read timeout (ms) |
| Timeout | soWriteTimeout | 30000 | Socket write timeout (ms) |
| Failover | maxReconnectAttempts | 5 | Maximum reconnection attempts |
| Failover | initialReconnectDelay | 1000 | Initial connection delay (ms) |
| Performance | tcpNoDelay | true | TCP Nagle algorithm disabled |
| Performance | socketBufferSize | 65536 | Socket buffer size (bytes) |
| Prefetch | jms.prefetchPolicy.queuePrefetch | 1000 | Prefetch count for Queue |
| Prefetch | jms.prefetchPolicy.topicPrefetch | 1000 | Prefetch count for Topic |
| SSL | needClientAuth | true | Client certificate required |
| SSL | verifyHost | true | Host verification active |
Common Usage Scenarios
| Scenario | Protocol | Recommended URL |
|---|---|---|
| Development | AMQP | amqp://localhost:5672 |
| Development | TCP | tcp://localhost:61616 |
| Test | AMQP | failover:(amqp://test1:5672,amqp://test2:5672)?failover.maxReconnectAttempts=3 |
| Test | TCP | failover:(tcp://test1:61616,tcp://test2:61616)?maxReconnectAttempts=3 |
| Production | AMQP | amqps://prod:5671?transport.trustStoreLocation=/certs/truststore.jks&failover.maxReconnectAttempts=-1 |
| Production | TCP | failover:(tcp://prod1:61616,tcp://prod2:61616)?randomize=true&maxReconnectAttempts=-1 |
| High Security | AMQP | amqps://secure:5671?transport.verifyHost=true&transport.trustStoreLocation=/certs/truststore.jks |
| High Security | TCP | ssl://secure:61617?needClientAuth=true&keyStore=/certs/keystore.jks |
| High Performance | AMQP | amqp://fast:5672?jms.prefetchPolicy.all=2000&amqp.maxFrameSize=1048576 |
| High Performance | TCP | tcp://fast:61616?tcpNoDelay=true&socketBufferSize=131072&wireFormat.maxFrameSize=104857600 |