Sending messages one at a time.

[Derek Stukey]

Hello all,

We are running Cloverleaf v5.3 and have been asked if it’s possible to perform the following task:

* When an ancillary system comes back up from a downtime, the end user would like one message to come across for testing purposes.  If necessary, sometimes more than one message might also be needed.

The easiest method for us, would involve bringing up the appropriate thread for a second and then bringing it down again.  Unfortunately, based on the speed of the server, usually more than one message would go through during that duration.

Disregarding ideas that require lots of configuration, is there a quick way to slow the message transmission speeds anytime?  Or, are there any known utilities (internal or 3rd party) which could assist in the process?

Thank you,

Derek Stukey

Topic

[Russ Ross]

I will describe the downtime methodology I architected that will accomplish what you want.

However, it may not meet your desire to implement an effortless solution but it has proven to be a very effect method for handling down times.

For every outbound production thread I have 4 other threads in a mock site I use for down times.

During a downtime I configure the outbound thread to point to local host (127.0.0.1) and recycle the thread to pick up the change.

Then in the mock site I turn on the mock thread that pretends to be the foreign system which static raw routes everything to a dump thread.

When ready to come out of down time mode, I have tons of options; so in your case you could take and send one message from the dump file to get comfortable before sending the rest.

If you are smart and make a copy of the dump file you can even screw up and still be able to resend if necessary.

I continue the cycle of dump –> load –> resend until I get caught up, then I shutdown all my interfaces in the mock site, then I switch the production outbound interface to no longer point to the local host mock interface and back to the real foreign system interface.

By the way, I created a standard that requires all port assignments be unique which is important with this model but makes common sense under any circumstances.

Attached are some screen shots of the real site and the mock site to help visualize what I’m describing.

Russ Ross
RussRoss318@gmail.com

[Russ Ross]

In addition to my previous post, the configuration of the load thread in the mock site needs to be protocol fileset-local throttled to an appropriate speed that will not exceed the capacity of the foreign system when it comes back up.

This is one of keys to success after being down for a long time and amassing 500,000 messages.

You don’t want to overwhelm the foreign system or crash the cloverleaf process by sending them too fast.

In the attached screen shot example, it will grab 500 messages every 60 seconds.

This setting could also be altered to accomplish sending just 1 at a time but I would probably choose to just create a file in the load directory with just one message.

I personally like to find a setting that will result in about 15 seconds or more of idle time before grabbing the next specified handfull of messages.

Russ Ross
RussRoss318@gmail.com

[Michael Hertel]

Wow Russ, that a very elegant solution! Great work!

The only thing we came up with here is to kill the ACK message before processing the check_ack proc.

The engine thinks it hasn’t received the ACK and goes into retry/timeout mode. Therefore you’ll send the same message over and over using your timeout settings.

[Derek Stukey]

Russ,

Thanks for your help!  I will give this a try and see how it works.

[Author]

Replies