Thread Forwarding Limitations

[Bob Richardson]

Greetings,

[We are running Cloverleaf 5.3 Rev3 on AIX5.2]

Folks, I have been experimenting with thread forwarding as a method to handle outbound connections that disconnect from Cloverleaf and back up messages in the recovery database.  We have an application – Emageon – that runs into trouble often enough to require saving off messages and resending later – sometimes days later.

So… I had created a common forward thread that a process cluster would feed if any one of its 14 outbound connections disconnected.  Setting the forward thread (fwd thrd) to fileset local and building a TPS OB tcl to handle saving messages based on DESTCONN and individual counter files,

everything worked fine when only one outbound was set to forward (even added maxrecs to the mix).

Broke when trying to set another thread to forward to the same fwd thrd connection.  The first time, ok:  messages forwarded to the common fwd thrd.  Then more messages arrived and nothing happened!  Stuck in State 11 of the outbound threads.  Repeated ‘forward starts’ did not fix the issue nor did ‘forward stop’ of the other forwarding thread.

So… set up individual fwd thrds for each outbound and then once forwarding was enabled (forward start) for each outbound thread then messages consistently flowed into the fwd thrds.

My apologies for this long post but just looking for confirmation that I am not going nuts and that thread forwarding is limited to one dedicated fwd thrd per outbound thread – no sharing here.  It would be great if many outbounds could forward to a common ‘fwd thrd’.

Thanks for any response and for your patience in this post.

Topic

[Jim Kosloskey]

Bob,

We are CL 5.2 latest rev for 5.2 and I think AIX 5.2.

Anyway, I have not tried to do what you are trying with forwarding.

However, there are additional improvements I would like to see in Forwarding:

There needs to be some indication in the NetConfig asnd NetMonitor GUIs of the route between potentially forwarded thread and it’s forward thread target. A dotted route line would work.

There needs to be a visual indication when the thread is actually forwarded. Such as turning the dotted route line to solid and the normal route line to dotted and indicating in the forwarded thread that it is indeed forwarded instead of or in addition to ‘Up’.

There neeeds to be a mechanism for making the forwarding persistant such that once the thread is forwarded it stays forwarded until the forwarding is stopped. At this release, if you cycle the forwarded thread, when the forwarded thread is restarted, forwarding stops.

For the above reasons we do not use forwarding here but probably would if the suggested improvements were made.

Once we began to use it perhaps more enhancements could be determined.

I think this is a functionality which could be quite useful for outage situations if it worked properly.

Thanks,

Jim Kosloskey

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

[Bob Richardson]

Greetings,

  Thanks Jim for your reply.  I had seen an earlier post from you with the points stated and agree wholeheartedly with each of them!  I was hoping to take advantage of functionality that is available on Cloverleaf rather than being driven into creating a custom solution around Cloverleaf’s limitiations here.  For instance, the indication of ‘forwarding status’ occurred to me as well: in my Tcl code I set a ‘fowarding flag signal file’ in the process directory as a visual aid and then remove it once the thread is cycled.  At least a support person would know that something (someone) cycled and thus disabled thread forwarding.

  The biggest limitation is not being able to forward a cluster of threads in the same process to one receiving forward thread – at least, based on my current testing.

   Perhaps a Quovadx Cloverleaf guru might have some insights into thread forwarding for us?

   Anyway, thanks again for your reply!

[Russ Ross]

Like Jim Kosloskey has already pointed out that we could not bring ourselves to use thread forwarding with the current behaivor.

However, we did come up with an alternative solution for handling extended down time that sitll uses cloverleaf without any custom coding.

If you are interested in looking at our downtime methodology, there is a detail description at URL

https://usspvlclovertch2.infor.com/viewtopic.php?t=1621

This method does not work with special interfaces like UPOC protocol but I’ve had to come up with a similar way of handling that type of downtime and can discuss with you off-line if that becomes an issue for you as well.

Russ Ross
RussRoss318@gmail.com

[Bob Richardson]

Greetings,

Russ, thank you for sharing your downtime methodology.  I will pass this information to our group here.  We have used filesets for extended downtimes of interfaces and that works well.  The idea of a separate site is a good one.

Thanks again for your post!

[Author]

Replies