Transactions per second throttling

[Keith McLeod]

I have a request from a vendor to slow down the number of transactions per second to less than 4 otherwise his system deletes messages.  I had suggested that they control the speed by throttling there acknowledgements.

Does anyone have a throttling method that they can share in case we need to put one in place.  I was thinking in the tps inbound reply using a proc in same location as you would use validate_reply and setting a sleep time.  Any thoughts or advice is welcome….

Topic

[Jim Kosloskey]

Keith,

If you add a sleep you will cause the entire process of which this thread is a member to sleep – I don’t think you will want to do that.

Of course you could put that thread in its own process all by itself and do the sleep – but then you incur cross process concerns…

You could put their messages to a num file thread, then pick those files up with another thread using the Fileset/FTP protocol throttling capabilities and send those to the final destination.

As you have already determined the proper way to do this is the receiving system must pace via acknowledgment timing. Of course, that is likely to cause a queue to build up on the Cloverleaf(R) outbound thread.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Bryan Dort]

Keith, I agree with you and Jim that this should be handled by the vendor. Maybe you can push a little harder for them to fix their code.  

The tcpip-pdl HL7 assumption has to be that if an acknowledgment reply is received, then the next message is ready to be sent…that is, as fast as they send you replies, you should be able to send them messages.  (easy for me to say…right?)  

😉  Having said that, there are situations that I have run into that a vendor is unable, or just plain unwilling, to make a change like this.  

In that case, a solution like Jim described sounds like the way to go (“num-file” to fileset-ftp.)  It adds an extra step in the translation, but it doesn’t pause the entire process.

[Author]

Replies