Process configuration – separating in and outbound threads?

[Peter Heggie]

Are there advantages, disadvantages or problems associated with assigning all the outbound threads associated with an inbound thread to the same process as the outbound thread?

Our main HIS inbound thread is in the same process as all of the outbound threads that are referenced as destinations for that inbound thread’s routing. An option we are thinking about is to group all inbound and outbound threads for the same ancillary in their own process, and have a separate process to hold the main HIS inbound thread.

Using the current configuration means that recycling the main inbound thread will also stop all of the connections to all the ancillaries. But I heard of problems occurring years ago, with keeping related inbound and outbound threads in separate processes. However I don’t know what those problems are. Perhaps there were problems but these were fixed in newer releases of Cloverleaf.

Possibly performance could change if outbound threads are moved into a different process, because then messages must flow across machine processes? Maybe there is more I/O processing taking place? But our machine is nowhere near maxed out so we probably would not notice it.

Also, if all inbound and outbound threads for an ancillary are grouped into a process, then all connections must be recycled if the process is recycled. This seems like a ‘six of one, half dozen of another’ type of comparison?

If we switch to a new HIS, which seems likely in about two years, we may need to support both old and new inbound threads for a while, and maybe having separate, inbound-only processes will help.

Any thoughts?

Peter Heggie
PeterHeggie@crouse.org

Topic

[Jim Kosloskey]

We do a similar architecture but using sites instead of processes.

Our Inbound thread is in a site which then sends to localhost threads which connect to other sites. We call this type of site a ‘distribution’ site.

The sites which are connected to via the ‘distribution’ site are called ‘delivery’ sites and they actually do whater work is required by the receiving systems and deliver the messages to them.

If you would like to discuss in more detail, email me and we can discuss off line.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Peter Heggie]

sent you an email

Peter Heggie
PeterHeggie@crouse.org

[Max Drown (Infor)]

Peter, Cloverleaf communication inside a process if faster than communication between processes. Cloverleaf uses TCP/IP for communication between processes. The general recommendation is to keep simple interfaces, like one-to-one communication inside of a single processes.

That being said, when your volume and routes increase, it becomes worth the extra processing to split your interfaces into multiple processes. It is very common to do as you describe, use a single process to focus on receiving messages and routing them raw to other processes for translation and destination routing. Exactly like you said, I prefer to put my destination threads into their own processes so that they rarely need to be bounced.

So a common scenario is to have a process for receiving messages, 1 or more processes for translation and destination routing, and 1 or more process for sending messages to destinations.

-- Max Drown (Infor)

[Author]

Replies