Transformations on Source Thread vs Destination thread

[kiran tummala]

We can have the routes written on both the source thread and destination thread.  What are the advantages of using the source thread as just a pass through and using the destination thread for including the pre processes, Xlates and post processing tcl processes.

My thought process is that, if we have all the routes defined in the source thread, then it will work on each message in a serialized way and make sure that it goes through all the routes we defined, before getting the next message.  If we write the routes for downstream systems on their own specific threads, it will distribute the processing to each of the individual threads.

please help me understand this process.

Topic

[Jim Kosloskey]

Where would you route to on the destination thread if it is the destination.

Moreover in order to do data rather than reply routing you would need a Tcl proc on the destination thread to OVER the message to the inbound side (by definition one expects the destination thread to ba an outbound connection) so the Route Data configuration could take control.

I think I know what you are trying to accomplish and multiple sites with cross site routing (a couple of ways to do this) would probably do the trick with no special handling vis-a-vis OVER.

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

[kiran tummala]

Jim Kosloskey

I was more thinking of just doing a raw publish in the source thread and do the heavy weight of message parsing and transformation in the destination thread.  I was thinking, if we have all the transformations happening in the source thread, then it would be unmarshalling each of the message and then work on the Xlates and then send it to outbound thread.

If My source thread has 10 outbound threads/routes, and all 10 need some kind of translates, it would slow down the process as the source thread will be processing messages in a serialized way.  

Please let me know, if you thought process is wrong.

thanks

[Jim Kosloskey]

email me and we can discuss off-line.

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

[Max Drown (Infor)]

Here is a diagram showing the best practice for configuring high-volume interfaces in the most efficient way for the CPU’s.

There are two basic principles:

1. Try to avoid using a different process for an inbound and an outbound thread.

2. Utilize multiple CPU’s by putting pairs of threads in their own process and uses tcp/ip (or “Destination Threads”) to communication between them. The “translation processes” do not need to be in the same site.

-- Max Drown (Infor)

[David Barr]

kiran tummala wrote:

If My source thread has 10 outbound threads/routes, and all 10 need some kind of translates, it would slow down the process as the source thread will be processing messages in a serialized way.

[kiran tummala]

I was misguided by the term threads and was more thinking that Process manages threads and each thread is a component in itself and will be doing work independent of other processes.  Now that its clarified that all the threads in a process are essentially running as one process, It makes more sense to have translates in the source thread to maintain sync.

thanks

Kiran

[Author]

Replies