Using tcp_acknak.pdl & mlp_tcp.pdl? Disc space issues?

[Jennifer Hardesty]

Greetings,

I’m writing on behalf of our team.  I want to state at the start that the situation I am about to describe is not one I chose to enter into, but I am in a position to seek a practical, objective solution.

Up until a few months ago, we only used mlp_tcp.pdl for all our ack/nak needs.  A new member to our team aggressively recommended that all local send/receive hand-offs should be handled with tcp_acknak.pdl, even though we make heavy use of the logs for auditing, especially routes, not just errors.  With tcp_acknak.pdl, there is nothing written to the log.

My understanding was that mlp_tcp.pdl is required for the in/out threads for foreign connections; otherwise, tcp_acknak.pdl should be used.  Instead, we have a mixture and there doesn’t seem to be any standard to how tcp_acknak.pdl is set up.  No consistency as to what should be in each field for the Inbound and Outbound tabs for the client or server or how it should be set up in conjunction with the mlp_tcp.pdl.

Now, we are having recurring issues in our test environment with logs filling up with the “no-match: no more phrases to try” error and the engine disc space running out of space so quickly that the alerts don’t have time to trigger.

Before I insist that everything be returned to mlp_tcp.pdl across the board, I am coming to the Gurus and asking what the correct way is that we should have set things up.  What should be in what fields?  Etc.?

Thanks in advance!

Topic

[Charlie Bursell]

IMHO, I would use the length-encoded TCP/IP for local interfaces.  Mush more ergonomic than MLLP.  We use MLLP in most places only because it is HL9 standard.

Use TCP/IP length encoded. On the sender side set to await relies then use hcitpsmsgkill as reply proc.  On receiver side you can return anything.  All you are doing is simply sayin :I got it”

[James Cobane]

Jennifer,

When you see the ‘no match’ error, it would indicate the pdl configurations aren’t configured the same on the local send/receive threads, i.e. the local outbound may have mlp where the local inbound is configured with acknak.

[Jennifer Hardesty]

James, I understand what you’re saying about configuring both localhost threads to match, but what do you do when you have the following scenario:

process_a

foreign_inbound => hs1_adt_thread

                       => hs2_adt_thread

                       => hs3_adt_thread

process_b

hr1_adt_thread => js2_site_hub_thread

hr1_dx_thread =>

We would want to configure foreign_inbound with mlp_tcp.pdl because it is an incoming connection and requires proper ack/nak’ing.  However, the client/server pair hs1_adt_thread/hr1_adt_thread and hr1_dx_thread and js2_site_hub_thread with their hypothetical matches are all “local” and can be configured with no or minimal ack/nak’ing — tcp_acknak.pdl.

However, in some cases, we have found that having mlp_tcp.pdl as the server in a thread such as foreign_inbound routing to a client with tcl_acknak.pdl, errors are generated.  Sometimes, it’s only a single error per message received and sometimes, the error spins out of control and fills up the log at a rate of a few per minute.

So what are we doing wrong?

[Bob Richardson]

Greetings,

On a possibly related note here:  for all of our Outbound only threads,

in the INBOUND tab for a thread configuration,  check the “Outbound Only” box as this will prevent all but REPLIES from being received back from a remote site.   Unless of course you need to route the REPLIES!!

What this option does is to only allow Reply type messages back on an outbound only thread and toss the rest.  We sometimes get back rogue “replies” that the engine (Cloverleaf Integrator) tags as “data” and tries to route through the Inbound Data flow of the thread.  We receive other garbage unsolicited from applications like “account locked” notices from an application for example.

Hope this proves useful.

[James Cobane]

Jennifer,

The issue that your having sounds rather odd; the protocol configuration of one connection should not impact the configuration of another connection (unless they are talking to each other).  I suspect that the error lies within the individual configuration of the thread, and not the result of any relationship between the source inbound and destination outbound.  I know this doesn’t provide any “real” help, but I think the hypothesis of the inbound mlp affecting the outbound acknak may be a bit of a red herring.

Jim Cobane

Henry Ford Health

[Daniel Lee]

I had something similar happen to me once with the lenght-encoded TCP/IP MLLP but it was also accopanied with messages backing up on the outbound localhost thread.  It just resolved itself after a while but the logs were full of “no-match: no more phrases to try”.  After hours of troublshooting the only thing I could think of that made sense is that some other interface tried to connect to the reciving localhost thread and hijacked my TCP/IP socket.  Whatever hijecked my socket must have been using the mlp_tcp (or just wasn

[Bob Richardson]

Greetings,

Would like to chime in again after having read all of the current responses.

It looks like you want something like the following:

Remote_A (MLLP PDL Client) –> Local_A (MLLP PDL server) sends back ACK via TPS IB TCL proc (creates reply OVER)

Local_A (MLLP PDL Server) Routes –> Local_B (TCP/IP Client) NO ACKs just gets the message in its TPS OUTBOUND context.  OUTBOUND ONLY is checked on the Client guy here.  Await replies enabled TPS OUTBOUND tab.

Local_B (TCP/IP Client) –> Local_C (TCP/IP Server) gets the messages and sends back ACK (could be length encoded between the two as Charlie indicated above or just negotiate some short string).

Local_C (TCP/IP Server) Routes to whomever. And so on.

Bottom line:  as in the above discussions Keep the protocols in sync.

We got badly burned when we configured local host bridges with different protocols that were not designed to communicate with each other.

We did this for efficiency but developers “forgot” this model and we quickly got out of control.

We decided to keep things simple/stupid and keep all of our bridging and other TCP style protocols the same – yes, not efficient but we now have Virtualized frames running our engines and memory/capacity is outrageous.  Lends itself to tolerating “inefficiencies” of design to simplicity of development.

Holpe this helps and my apologies for any implicit snarking!!

[Author]

Replies