Skip to content

Exstream JMS connector throws IOException after output is created

Historical eraDialogue and HP Exstream 6.x-7.x JMS integration

By Tomas Hajek, working with Exstream since 2008. Published 2026-04-23

Applies to: Classic Dialogue and HP Exstream JMS on-demand processing; mechanism-based diagnosis without current official confirmation.

Symptom

The engine starts, composes output successfully, then throws IOException while routing the result. The log shows a generic failed to route message from the JMS layer. The failure looks intermittent, and in the worst variant a segmentation fault or process crash follows the routing error.

Cause

The likely mechanism: the connector is trying to send the response to a temporary reply queue that no longer exists.

The sequence goes like this. A requesting client sets a temporary queue in the message's reply-to attribute and waits. Eventually it gives up and closes its connection, which destroys the temporary queue. But the request is still in the system with an effectively unlimited time-to-live, so the engine picks it up, composes the output, and only then discovers that the reply destination is dead.

The IOException is a wrapper around the middleware's routing failure. It is not, on its own, evidence of a local file or permission problem, even though the exception type suggests one. This diagnosis is single-source and historical; treat it as the leading hypothesis to verify, not established fact.

Fix

Look at three request attributes together: the reply-to destination, the time-to-live, and the client's wait interval. The rule that prevents the failure: request time-to-live must not exceed the period the client keeps its temporary reply queue alive.

To isolate the fault domain, reproduce the case with a durable reply queue. If the durable queue works, the problem is destination lifetime; if it fails too, look at queue manager storage and permissions. Also capture the underlying JMS provider exception and the queue name in your logging; the Exstream-level IOException alone is too generic to diagnose from.

If the engine crashes after the routing error, treat the crash as a separate runtime defect and escalate it with the same reproducing request.

Preserve the failed request and reply destination

Do not clear the queue first. That removes the evidence without fixing an expired reply queue. A successful batch run is also irrelevant because batch output does not exercise on-demand reply routing.

Related Exstream notes.

Resolve can check the pattern against your environment.

Resolve searches your approved sources and shows its citations. If the evidence is weak, the same case reaches an experienced Exstream specialist with the evidence attached.

These articles describe field experience and identify the Exstream versions they cover. They are not official vendor guidance. CCMForge is independent and is not affiliated with or endorsed by OpenText. OpenText and Exstream are trademarks of their respective owner.