The caller sees GENERAL_PROTOCOL_EXCEPTION [100] instead of the message-handler payload. Follow the request from system.util.sendRequest through the local gateway, the Gateway Network connection, the receiving gateway, and the remote handler. Error 100 is the acknowledgement returned to the caller; the receiving gateway log identifies where processing actually failed.
Where does the request stop?
The data path has four decision points: the script submits the request, the local gateway selects an outbound Gateway Network connection, the remote gateway decodes and dispatches the request, and the message handler returns a serializable response. A failure at any point can surface at the caller as the same general protocol exception.
| Hop | Reading to take | Failure meaning | Next check |
|---|---|---|---|
| Calling script to local gateway | Full Jython and Java exception chain | The call failed before a payload returned | Find the first Caused by entry |
| Local gateway to remote gateway | Outbound and incoming Gateway Network states | A faulted or unapproved connection blocks messaging | Check physical reachability and approval |
| Remote protocol endpoint | Remote log at the request timestamp | The remote gateway rejected, could not decode, or could not dispatch the request | Classify the remote exception |
| Remote message handler | Handler execution log and returned object | The handler failed or returned data that could not cross the connection | Test the handler and payload separately |
The caller-side trace passes through GatewayInterface.sendMessage, GatewayInterface.invoke, and SystemUtilities.sendRequest. It then reports a RemoteException handled by AckErrorHandler. That sequence means a remote error acknowledgement came back; it does not identify the remote cause.
Does layer one carry the Gateway Network connection?
Layer one first. Confirm that both gateway hosts are reachable across the actual route and that intermediate firewalls, proxies, address translation, and TLS termination permit the configured Gateway Network endpoint. Use the address and port shown in each gateway's connection settings; no port number is established by these incidents, so substituting an assumed default can test the wrong path.
| Item | Reading | Pass condition | Failure branch |
|---|---|---|---|
| Remote address | Configured gateway endpoint | Resolves or routes to the intended remote host | Correct name resolution or routing |
| Remote port | Configured listener port | TCP connection reaches the intended service | Correct firewall, listener, or forwarding rules |
| Transport state | Gateway Network status at both ends | Both ends remain running during the request | Resolve disconnects before testing handlers |
| Request timing | Caller and remote log timestamps | A remote event appears for the same invocation | If no remote event appears, remain on the transport branch |
One observed setup had an outgoing connection between 8.0.0-beta0 (b2018111302) and 7.9.9 (b2018081621) marked faulted. The connection label did not make its direction fully clear, but either interpretation leads to the same decision: message handlers cannot operate until the required Gateway Network path is established.
Is the remote gateway approved and running?
On the receiving 8.0 gateway, inspect Configure -> Gateway Network -> Incoming Connections and approve the 7.9 system if it is awaiting approval. Then inspect connection status on both gateways rather than relying on one side. A local running indication proves only that the local connection manager considers its side active; it does not prove that a particular remote service call can be decoded and executed.
| Connection result | Interpretation | Action |
|---|---|---|
| Faulted on either gateway | The messaging prerequisite is missing | Repair reachability, configuration, trust, or incoming approval |
| Awaiting approval | The receiver has not admitted the peer | Approve the expected gateway, then reconnect |
| Running on both gateways, no remote request log | The displayed connection and request path disagree | Recheck direction, destination selection, and timestamp correlation |
| Running on both gateways, remote exception logged | Transport succeeded; processing failed above it | Classify the remote exception before editing network settings |
A running connection therefore moves the decision tree forward; it does not close the diagnosis. In the 8.0.13_RC (b2020051415) to 7.9.13 (b2019120915) case, both connections showed running while the 7.9 gateway logged a service-dispatch exception.
What does the receiving gateway log?
Collect logs from both gateways for one controlled request. Start immediately before the call, issue one system.util.sendRequest, and stop after the caller receives error 100. Match the events by timestamp, gateway names, and connection direction. The useful exception is normally on the machine that received the request or attempted to decode the reply.
| Caller symptom | Remote exception | Failure layer | Decision |
|---|---|---|---|
GENERAL_PROTOCOL_EXCEPTION [100] with a faulted connection |
No matching remote processing event | Gateway Network transport or admission | Repair the connection first |
GENERAL_PROTOCOL_EXCEPTION [100] |
NoSuchMethodException for GanNodeDetailsService.getPlatformVersion()
|
Remote service interface | Treat the mixed-version service contract as incompatible |
GENERAL_PROTOCOL_EXCEPTION [100] |
StreamCorruptedException: invalid type code: FF |
Java object decoding | Treat the serialized message format as incompatible or corrupt |
| Error 100 with a handler exception | Application exception naming handler code | Message-handler execution | Correct the handler and retest |
Do not stop at the outer GenericTransferrableException. It is a container used to transfer the failure back across the connection. Continue down the remote stack until the first concrete exception names a service method, decoder, handler, or data type.
Does the failure indicate a mixed-version service mismatch?
The NoSuchMethodException branch is explicit: the receiving 7.9.13 (b2019120915) gateway attempted to resolve GanNodeDetailsService.getPlatformVersion(), but that method was unavailable to the receiving runtime. The request reached ServiceManagerImpl.invokeService and failed during service invocation. Network tuning and repeated connection approvals cannot add a missing Java method.
The serialization branch is different but reaches the same operational decision. A request from 7.9.14 to 8.0.10 produced StreamCorruptedException: invalid type code: FF on the 8.0 gateway. The stack entered JavaSerializationCodec.decode, so transport delivered bytes to the remote decoder. The decoder could not reconstruct the object stream. This is not a message-handler name lookup failure and not proof of a closed port.
| Observed pair | Connection condition | Remote failure |
|---|---|---|
8.0.0-beta0 (b2018111302) and 7.9.9 (b2018081621)
|
An outgoing connection was reported faulted | Messaging prerequisite not established |
8.0.13_RC (b2020051415) and 7.9.13 (b2019120915)
|
Running on both gateways | Missing getPlatformVersion() service method |
7.9.14 to 8.0.10
|
The request reached the 8.0 decoder | Object stream rejected with type code FF
|
These combinations show two independent gates: establish the network connection, then establish application-level compatibility. Read the supported interoperability or upgrade guidance for the exact installed builds before selecting replacement versions. The incidents identify failing combinations but do not identify a universally fixed build.
Could the handler or payload be the next fault?
After the gateways use a compatible software combination, separate handler execution from payload transport. Invoke the handler locally where possible and confirm that its code completes. Then send a minimal request containing simple values and return a minimal payload. Add production fields incrementally until the failing value is isolated.
This step matters because Gateway Network messaging must encode the request and response. Runtime-specific objects, open resources, Java objects without a compatible serialized form, or objects whose class definitions differ between gateways can fail outside the visible handler body. A successful local call proves handler logic, while a successful minimal remote call proves routing, dispatch, and basic encoding. Neither test alone proves the production payload.
| Test | Result | Meaning |
|---|---|---|
| Local handler test | Fails | Repair handler logic before testing the network |
| Local test passes; minimal remote request fails with service-method exception | Fails before handler execution | Resolve gateway-version compatibility |
| Minimal remote request passes; production request fails in the decoder | Payload-dependent failure | Add fields one at a time and replace the first non-transferable value |
| Request reaches handler; return path fails | Response-dependent failure | Reduce and rebuild the returned payload |
How do you resolve and verify the working branch?
- Record the full version and build from both gateways. Preserve the exact direction of the request and the direction of every configured Gateway Network connection.
- Read the configured remote address and listener port. Verify name resolution, routing, TCP reachability, and any TLS path against those settings.
- On the receiving 8.0 gateway, open
Configure -> Gateway Network -> Incoming Connectionsand approve the expected 7.9 gateway when approval is pending. - Wait for both gateways to report the relevant connections as running. If either side faults, collect both connection logs and remain on the transport branch.
- Issue one controlled
system.util.sendRequestcall and correlate the two gateway logs by timestamp. - If the remote gateway logs
GanNodeDetailsService.getPlatformVersion()as aNoSuchMethodException, move the gateways to a software combination documented to support their required Gateway Network messaging path. - If the remote gateway logs
StreamCorruptedException: invalid type code: FFinJavaSerializationCodec.decode, align the gateway software combination first, then retest with a minimal payload before restoring production data. - If transport and service invocation pass, test handler execution locally, then expand the remote request and response one field at a time.
- Run the original request again. Pass only when it returns the expected payload, both Gateway Network connections remain running, and neither gateway records a matching error acknowledgement, service-method exception, decoder exception, or handler exception.
FAQ
How do I find the real cause of Ignition error 100?
Trigger one request and inspect both gateway logs at the same timestamp. The caller's GENERAL_PROTOCOL_EXCEPTION [100] is an acknowledgement; diagnose the first concrete exception on the remote gateway.
How do I fix sendRequest when the Gateway Network is faulted?
Verify the configured address and port, repair the route or listener, and approve the peer under Configure -> Gateway Network -> Incoming Connections. Do not retest the handler until the required connection is running on both gateways.
How do I diagnose getPlatformVersion NoSuchMethodException?
GanNodeDetailsService.getPlatformVersion() failing on 7.9.13 (b2019120915) during messaging with 8.0.13_RC (b2020051415) identifies a mixed-version service-interface failure. Select a documented compatible gateway combination rather than changing network settings.
How do I verify an Ignition message-handler repair?
Send the original request and confirm that it returns the expected payload, both Gateway Network connections stay running, and the correlated logs contain no GENERAL_PROTOCOL_EXCEPTION [100], NoSuchMethodException, StreamCorruptedException, or handler exception.