Checkpoint Lab — JMS, FTP, LDAP, TCP, and Other Protocol Test Patterns

1. Exact assumptions and hard ceilings

2. Setup and target authorization/preflight

1. Start tcp_line_fixture.py on 127.0.0.1:9100 with a fresh JSONL log.
2. Run one manual PING client and archive/clear that preflight event file before measured runs.
3. Record Python version, JMeter 5.6.3, Java version, fixture version/listen address.
4. Verify no other process/endpoint is used.

3. Persistent checkpoint tree

Test Plan
├── TCP Sampler Config
│   TCPClientImpl
│   127.0.0.1:9100
│   Re-use connection=true
│   Close connection=false
│   EOL=10
│   Connect Timeout=500ms
│   Response Timeout=1000ms
└── Thread Group — 2 threads × 5 loops
    ├── TCP Ping A
    │   Text=PING|T${__threadNum}-${__time()}|hello-${__threadNum}${__char(10)}
    │   └── RegEx Extractor CONN_A = CONN=([^|\r\n]+)
    └── TCP Echo B
        Text=ECHO|T${__threadNum}-${__time()}|second-${__threadNum}${__char(10)}
        └── assert response contains CONN=${CONN_A}

4. Predictions before persistent run

Prediction A — connections: the two JMeter threads should open approximately two fixture connections and reuse them for all 20 request/reply samples.

Prediction B — isolation: each thread's Ping A and Echo B response within a loop should report the same connection ID; different threads should normally have different connection IDs.

Prediction C — cleanup: JMeter closes sockets when the test ends, so fixture disconnect count should eventually match measured connection opens and active connection count return to zero.

5. Run persistent profile

jmeter.bat -n `
  -t plans\checkpoint-tcp-persistent.jmx `
  -l results\persistent\results.jtl `
  -j results\persistent\jmeter.log `
  -e -o results\persistent\report

Record generator CPU/memory/socket count during the run. Keep the fixture event log for this profile separate.

6. Verify persistent predictions independently

python tools/analyze_tcp_events.py results/persistent/tcp-events.jsonl

Require:

• 20 request events;
• approximately 2 measured TCP connections;
• multiple requests per connection;
• max active connections ≤2;
• no duplicate request IDs/ERR statuses;
• JTL zero unexpected failures.

7. Change one variable: disable connection reuse

Duplicate the exact JMX and uncheck Re-use connection. Keep target, threads, loops, payloads, EOL, timeouts, and assertions unchanged. Start a fresh fixture log.

Prediction D: approximately 20 measured TCP connections are opened—roughly one per sampler—while total request count remains 20.

8. Run and compare per-sample profile

jmeter.bat -n `
  -t plans\checkpoint-tcp-per-sample.jmx `
  -l results\per-sample\results.jtl `
  -j results\per-sample\jmeter.log

Compare connection opens, max active sockets, elapsed distribution, generator/socket state, and server event counts. Do not call any timing difference “TCP server capacity”; the experiment only changes client connection lifecycle under tiny local load.

9. Request/reply timing proof

Run a separate 1-thread ×5-loop profile:

DELAY|T${__threadNum}-${__time()}|25${__char(10)}

Prediction E: each response reports DELAY_MS=25 and JMeter elapsed is at least approximately 25 ms plus loopback/client overhead. Preserve fixture service_wall_ms so client/server timing can be compared.

10. Verify target cleanup

After each profile, wait briefly for JMeter sockets to close, then verify event log connect/disconnect parity and zero active connections. Stop the fixture only after verification.

The protocol has no persistent messages/files/database rows, so socket closure and event-log completion are the target cleanup contract.

11. Second-protocol architecture — JMS request/reply

Design the equivalent experiment without executing it:

Minimum provider prerequisites if later executed: pinned matching provider/JNDI JARs in every JMeter injector lib, JMeter restart, localhost/private authorized broker, synthetic credentials, run-scoped destinations/IDs, explicit reply timeout, and cleanup verification.

12. JMS predictions before any future run

JMS Prediction 1: Request Only can show successful low send latency even if reply/consumer processing never occurs; queue depth/consumer telemetry must reveal that.

JMS Prediction 2: Request Response cannot complete successfully until the configured reply/correlation path produces a reply or timeout occurs.

JMS Prediction 3: missing provider JAR/JNDI class fails on generator setup and should produce no meaningful broker message load.

13. Required evidence packet

14. Validity statement

15. Verification checklist

• Target exactly 127.0.0.1:9100.
• TCPClientImpl and EOL=10 documented.
• Request strings terminate using ${__char(10)}.
• Persistent profile ≤2 connections and 20 requests.
• Per-sample profile ≈20 connections and 20 requests.
• All responses have expected command/request/connection evidence.
• 25 ms delay run has matching client/server timing evidence.
• No unexpected errors/timeouts; no active connections after run.
• JMS second-protocol design includes provider JARs, correlation, reply timeout, queue-depth and cleanup evidence.

16. Cleanup / rollback

1. Stop JMeter profiles.
2. Verify all TCP connections disconnected.
3. Stop tcp_line_fixture.py.
4. Retain JTL/jmeter.log/event logs until review completes.
5. Delete only disposable local fixture/result files after review.
6. No external broker, FTP server, LDAP directory, provider JAR, plugin, container, credential, or production system was changed.

17. What Chapter 17 adds to the operating model

The production performance-testing operating model now has a protocol-semantics contract: sampler/client/provider version, connection/session lifecycle, payload framing or message/file/directory operation, acknowledgement/reply boundary, unique correlation/client IDs, credential/trust rules, target queue/file/session state, cleanup evidence, generator dependency/classpath state, and protocol-specific interpretation of elapsed/latency are reviewed before results become evidence.

Chapter 18 moves to File Uploads, Downloads, Multipart Requests, and Large Payloads. That chapter returns primarily to HTTP/file-transfer payload mechanics and focuses on body/file size, multipart encoding, generator disk/memory/network cost, hashing/validation, storage cleanup, and safe large-payload workload design.

Knowledge check

Official references and version notes

• JMeter Component Reference — TCP Sampler — built-in TCP clients, EOL/binary framing, per-thread connection reuse, timeouts, and socket lifecycle.
• JMeter Component Reference — FTP Request — upload/download behavior, login latency, binary/ASCII modes, and credential storage.
• JMeter Component Reference — JMS Publisher — provider/JNDI dependencies, destinations, persistence, message sources, and provider JAR requirements.
• JMeter Component Reference — JMS Subscriber — queue/topic clients, durable IDs, selectors, receive/listener strategies, and connection lifecycle.
• JMeter Component Reference — JMS Point-to-Point — request-only, request-reply, read, browse, and clear semantics.
• JMeter Component Reference — LDAP Request — Add/Modify/Delete/Search operations and cleanup differences.
• JMeter Component Reference — LDAP Extended Request — bind/session-oriented LDAP operations.
• JMeter Functions — __char — inserts explicit Unicode characters such as LF for TCP text framing.
• JMeter Getting Started — Java requirements and GUI authoring versus CLI execution.
• JMeter Best Practices — non-GUI execution and generator validity.
• Apache JMeter downloads — current stable release and Java requirement.