- This topic has 18 replies, 5 voices, and was last updated 14 years, 10 months ago by
.
-
Topic
-
Good afternoon, I was just wondering if there was a way to throttle output from a thread to a file using one of the pre-defined protocols in Cloverleaf like Fileset-Local or Fileset-FTP?
For instance: Every 10minuts, FTP the file the thread is writing and create a new file with a different name; possibly using a counter or hhmmss.
I know that you can throttle and schedule in-bound reading from file with Fileset-local, but it doesn’t appear that the scheduling options apply to data being written to a file.
Would this have to be coded in a Tcl Proc? Has anyone done something like this before?
Thanks!
Troy
-
Replies
-
-
I am not sure why you would want to slow the file delivery down since you essentially have a dedicated device but perhaps Xlate throttling will help (if you are using an Xlate).
Otherwise,
I guess you could put a Tcl proc in place (Outbound Tps perhaps) that has a sleep before continuing – just remember this is a blocking command and will block the Process.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
OK I get the picture.
However, slowing the pace you write to the file that Meditech picks ups might not get the results you are looking for.
I am pretty sure Meditech is not reading the file while you ar writing to it (at least they should not – collisions you know).
So I think it might be the pace at which Meditech reads the file you provide that might need to be adjusted.
If the above is true and Meditech can’t or won’t adjust their read pace, then you might have some effect by applying Translation Throttling on the process that receives the ADT from Meditech. But that has potential ramifications that should be thoroughly analyzed.
Of course you could put a sleep on the acknowledgment proc you are using to send the acknowledgment to Meditech but once again that is blocking and will affect that process (but then so does translation throttling) and have other potentially unintended consequences.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
OK
I was speaking about a delay on your real-time ACK to the ADT messages Meditech is sending but that is not something I would recommend.
Will meditech process all of the files in the directory where you place your data at one time?
How often does Meditech check for files to process?
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Oh, yes, trying to delay the in-bound is an option too, but we’re trying hard to eliminate any delays in the ADTs to downstreams. We could also put a delay on the inbound from Softmed Abstracting batches, which is really the root of the issue, but the Softmed folks said they prefer not to hold a large queue of messages on their end while we process through them slowly, so that was out.
I’m not completely clear on how the Meditech side works but I believe that they will process one file at a time (becasue the file has to have a certain name). We would like to change this so that we could drop multiple files using a naming convention which would reduce the risk of us accidently overwritting a file.
Meditech scans the directory constantly, so as soon as a file is dropped, they process it.
-
-
The in-bound from Softmed is realtime mlp-tcp. We batch the inbouncd ABS charges into a file and FTP (Samba) them to Meditech. The current process batches the Charges for the entire day and sends them all at once around 8:00pm. There are between 300 and 800 charges per day, hence the deluge of 300-800 A08s all at once when the file is processed.
We want to switch this to a more real-timeISH feed that will send the files in batches of 10, 20 or 50 (TBD) 24/7 to eliminate the deluge of A08s created when the entire batch is processed all at once.
I was hoping that we could do this just using the Cloverleaf protocol settings, but doesn’t look like we can.
Writing a proc won’t be horribly difficult, but I was hoping someone else had already done it, so I could (borrow) to save some work.
-
-
The batch_num_file solution I spoke of in another post today will do what you want.
Here is the URL again:
<a href="http://clovertech.infor.com/viewtopic.php?p=7043#7043″ class=”bbcode_url”>http://clovertech.infor.com/viewtopic.php?p=7043#7043One of my real-time to batch integration of real-time ADTs to Asset Trakker are done once a minute.
I even have an argument to control the maximum number of message to batch at one time.
I’m sorry to hear that 800 ADTs all at once is a problem for your cloverleaf shop.
That makes me wonder if you have yet to evolve to the multiple site mentality with processes isolated in ways to maximize through put.
I see you aready have the ear of one of my team mates (Jim Kosloskey) and he can certainly give good advice on the topic of breaking integrations into smaller independent pieces to achieve maiximum throughput if that is your real underlying problem.
I do understand a burst of 80,000 messages in a batch being a challenge but 800 in a burst seems a bit small to show up with the type of symptoms you are experiencing unless your cloverleaf integrations are all in one site.
Russ Ross
RussRoss318@gmail.com -
-
Troy:
If you postpone delivery of messages with several smaller batch files, you still might end up with the same 15 – 20 minute delay to the final destination.
I think the receiving system would have to figure out how to ACK faster to solve the real problem.
Sometimes we get slow interfaces but for the most part we require at least 3 messages a second thru put before letting an interface go into prodcution for an ADT interface unless we overlook load testing during development.
On today’s hardware this should be no problem unless poorly designed.
I’ve seen our lab interface move 75 messages a second and one team memember claims to have seen 100 messages a second.
Those are the top speeds so far and I consider 25 messages per second to still be a very fast interface in general even though that would be too slow for some of our thru put like with lab messages wich needs about 40 messages per second minumum.
I see many interfaces run as slow as 5 messages per second and some still struggle to get above our 3 messages per second minimum, but when I get down to one message per second or slower I begin to suspect I’m up against a poor or outdated deisgn.
Probably the biggest problem I see with very slow interfaces is the very old mindset of having the database import/post determine when to ACK the message.
Another common problem that slows an interface receiver down is excessive logging.
When I do the math of 800 messages takes 15 minutes that is about 68 seconds per messages which makes me wonder if the vendor interfaces interacts with something that sleeps one minute between processing each message.
If this is the case, look to fix the problem because you will be delaying message deliver potentially to other down stream systems that might be able to handle a burst of 800 messages.
In the begining when we were on our older cloverleaf servers up to cloverleaf 3.5.5 the process would crash around 8,000 messages and impacted other interfaces like you described.
When we moved to our current AIX IBM p570s about 4 years ago and broke up our sites and upgrade to cloverleaf 5.2.1P2, we have incurred and been able to handle message queue depths as high as 150,000 messages without noticeable cloverleaf impact.
I’m not sure where we would have a serious problem like a process crash because the 150,000 queued depth capacity has been large enough to handle our worst case seen thus far.
Russ Ross
RussRoss318@gmail.com -
-
Sorry I got my math wrong when I used 3600 instead of 60.
Thanks for pointing out it is one second per message and not one minute per message.
That type of delay is typical of the data import/posting being tied to ACKing.
Good luck with whatever improvements you attempt.
I must be missing something because slowing down message delivery upstream would seem to slow down delivery for all outbound receiving systems.
Perhaps I could infer these batch ADTs have a lower priority than the other normal ADTs.
If that is true there is a priority setting that can be lowered on those messages that might allow any ADTs queued to process before any of the batch ones.
I can’t vouch for the use of the message priority setting as a way of ordering the batch ADTs behind any other ADts but I would investigate that as a possible solution.
I’m sure there are other clovertechies that can speak to this if you think this shows any promise as a solution.
Russ Ross
RussRoss318@gmail.com -
-
We are in the process of performing a data load of 000’s of messages, where each message needs extra data from query (A19) and is then sent to the destination.
The query access and message delivery are required to be throttled to avoid queues.
I achieved this with the addition of one thread that read/wrote to a directory.
On the outbound context, I use the driver control to write to an ‘hourly’ file.
On the inbound directory parse context, I ensure that only 1 file is returned IF it is from the previous hour.
On the inbound read, I set the flow rate required.
We performed a data load of millions of records 5 years ago to a clinical manager application that queued message before processing – it was a half duplex communication. It also had memory leaks etc, so would slow down gradually – not the best!
To maintain maximum throughput, I used the internal queue on the outbound message delivery thread and inbound ack thread and only ‘released’ a file for processing IF the difference between these was below a threshold value.
Again the inbound directory parse context can be powerful. I wrote code to unzip and split SMAT files into ‘managable’ chunks, so we could ‘store’ 000’s messages ready for delivery.
-
Troy,
I am looking at your original post and I have done something similar to what you are trying to achieve. Instead of the FileSet protocol, you should consider using the UPoC protocol for your outbound thread. Under “UPoC Options — Write TPS” you would put the name of the Tcl script that will append your HL7 messages to a file, for example MYSCRIPT (your code would be in the “run” portion of the script). Under “UPoC Options — Read TPS” you would check the “Use Advanced Scheduling” box and set up your advanced scheduling to run every 10 minutes as you desire. Here the Tcl script should be the same one as the Write TPS (MYSCRIPT) and the “time” section would contain the code time-process the file as you desire.
Basically, the “run” section of the script keeps appending your HL7 messages to a designated file as they are received from the inbound thread. At regular intervals (10 minutes), the advanced scheduler wakes up the “time” section of the code which moves the accumulated file to another directory to be picked up by ftp.
If you use the FileSet protocol, you have to stop the thread when you want to grab the accumulated file because you never know when the thread is going to write. Using the scheme above with the UPoc protocol, you don’t have to stop the thread. Since the “run” and “time” sections are in the same script, they cannot run at the same time.
I don’t collect my files as frequently as you are planning to do (10 minutes) but I have never had any issue using the UPoC thread as stated above. If you are interested in exploring this avenue, send me your email address and I will show you some sample code.
I hope this helps.
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
