Most likely, this is a result of the inbound thread being in one process, and the outbound thread being in a different process. Sometimes the cross-process hand-off of the messages gets hosed (as there is a memory leak), and the messages start to queue in state 7 (post-Xlate). Normally, you need to stop and restart the process that the inbound thread is in to get the messages to process.
Thanks James for your explanation. I stop/start the process that the inbound thread was in and once I did that the messages changed from state 7 to state 11 and then they were sent to oubound thread and to the receiving system.
This occurs as a result of the cross-process communication between the inbound & outbound thread; i.e. you have the inbound thread in one process, and the outbound in another:
Process A Process B
Inbound
|
> Outbound
One way to alleviate this is to place the outbound thread in the same process as the inbound. Another option is to configure localhost tcp/ip connections to keep the inbounds & outbounds in the same process:
Process A Process B
Inbound —> Outbound … |… Inbound —> Outbound
(localhost) (localhost)
(client) (server)
You would then also want to move the translation that is being done into process B. If you don’t move the translation work from process A to B, you don’t really gain anything by this approach, and would be just as well served to but the original outbound thread in the same process as the inbound.
I would also add that you should report it to support. The engine was designed from the beginning to handle cross process communication and it would help to see a system in this condition since it’s very hard to recreate.
Author
Replies
Viewing 4 reply threads
The forum ‘Cloverleaf’ is closed to new topics and replies.