TCL tcp volume test – Read 0 bytes — peer disconnected?

[Peter Heggie]

I want to use a command line script on AIX to run a volume test, to input hundreds or thousands of HL7 messages to an inbound thread. The script will increment the MRN and PAN as it sends each message. There are some downstream threads and I will be measuring performance and looking for problems.

The TCL script is using a socket to connect as a client to the inbound thread which is setup as a PROTOCOL:tcpip server. It is set as ASCII length 10 fill 0.

When I run the script the message is accepted by the thread and sent downstream as expected, but I get the following error in the process log: Read 0 bytes — peer disconnected?

Unable to read msg length

It looks like it reads the message from IP, using the length in the first 10 bytes and grabs the expected remainder of the data as the message. Then it seems to go back to the socket and look for more data, but there is no more data because I am only sending one message at a time. How can I make it cleaner?

The command line script has this code:

set server “xxx”

set sockChan [socket $server nnnn]

fconfigure $sockChan -translation binary

   

   puts $sockChan $msg

flush $sockChan

close $sockChan

I’ve also tried appending another 10 bytes of a message length indicator, with a value of 0000000000 to indicate that there is no more data to read. I’ve tried appending CR, LF, CRLF, LFFCR, x1c.  I must be missing the point. Do I need to code/use a Reply or Ack tcl in my inbound thread to send back to the client TCL?

Peter

Peter Heggie
PeterHeggie@crouse.org

Topic

[Jim Kosloskey]

Peter,

Sometimes we simply do a resend in the NetMonitor on the inbound thread to do a volume test.

That seems to suffice.

Another option we have used less frequently is to set up a Fileset/Local thread to read a file (with ot without throttling – depends on what you are testing) and rawroute to an outbound thread (localhost). We change the inbound thread to localhost same port as the new outbound thread. then the messages read from the file are sent to the new ob-thread which then delivers to the old ib thread to be handled as if they arrived from another system.

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

[Peter Heggie]

Thank you. The first option, using NetMonitor, means preparing a suitable input file, with the 100,000 messages? That would be good practice for writing TCLs.

The second option is probably easier for me; an older version of my tcl writes X number of file copies for a given input message, with suitable incrementing of various data items, into a directory read by a fileset local inbound thread. I could make a modification similar to your suggestion to insert a thread after that file inbound thread. I could use the Hold function on the inbound fileset local thread so that messages would queue internally up to my desired test volume, and then release them to the second thread. This would more closely simulate the test conditions we need to prepare, for a mass conversion of close to 100,000 messages coming through at once. Hopefully Cloverleaf can queue up 100,000 messages.

I guess one of my questions was just basically, does anyone have a utility written in TCL that can submit messages to Cloverleaf via IP, and if so, how do they avoid that error message?

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

For the resend we get the messages by extracting approximately the number we want from the archved SMAT files then cat them together into one file – no Tcl needed.

So we archive in Test once per week. if we get less than 100000 in a given week, we simply use multiple weeks.

As far as the queueing, that is dependent on your machine’s memory and disk-based queuing settings.

As for ‘all at once’ is the conversion using a file or real time?

If a file (that would be my recommendation) then you can use fileset/local throttling to contol the flow of the messages (you will wan to do that ) to some reasonable arrival rate.

If real time then a constraint will be the rate at which the source system can deliver the messages to you.

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

[Peter Heggie]

Jim, thats great – I’ll use the SMAT files – thank you.  I believe the conversion will be done based on a master file on the mainframe and run through a utility in Siemens Invision, resulting in a flood of messages through the SNA connection to our Cloverleaf on AIX.

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

When faced with this kind of conversion or backload we have the source system (in our case also Invision) create a file which then the receiving system processes directlly (we may or may not be involved in delivering the file).

So Cloverleaf is not involved in the conversion/bakcload.

The reason to do that is frequently there are needs to restart the conversion process until it is correct (there can be more reasons than one would think).

This is more easily handled by the vendor of the receiving system than it is via Cloverleaf in our opinion.

We may have our realtime connections collecting and queuing messages from the cut-over time forward which then would be released once the conversion/backload is complete.

Invision sends messages from the commQ in a timed manner (that I believe is still set via profiles) so that could be throttled. However, Invision still uses 30 year old memory management techniques as far as I understand and the real issue will more likely be can the Invision environment tolerate 100,000 messages queued in the commQ?

Th

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

[Peter Heggie]

We have about 25 ancillaries that will take a conversion file; either the Invision consultants will give us this file, or we will use a new thread & translate that will create such a file. Hopefully it will be the former and we can get it to the ancillaries ahead of time. Two ancillaries can’t use a conversion file and must take real-time messages.

I will ask about throttling on the Invision side, and about its queing of that number of messages. We are preparing for a worst case scenario where we are responsible for the throttling for delivery to the two ancillaries, and where we need to have different throttling for each ancillary, as well as be able to restart or rerun messages, even specific messages. It is possible that these ancillaries will only take conversion messages at night, and it may take several nights to deliver all the messages.

The plan is to route to three destinations – a bulk file intermediate, and two ancillary intermediates. Each intermediate will write each message as a separate file into a directory (one directory per destination). This is streamlined as much as possible. Then there are three matching inbound threads that pick up the files, using Cloverleaf throttling, and deliver them to the ancillaries and the bulk conversion file.

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

Sounds like you have put quite a bit of thought into this and have a plan.

I hope all goes well for you.

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

[Peter Heggie]

thank you – quite a bit of thought, but then again, I’m a newbie, so there is a lot I have not considered.

Peter Heggie
PeterHeggie@crouse.org

[Author]

Replies