empty reply from server – using curl

I am working on a similar issue.

What I plan on doing is putting a catch around the curl::transfer command and trapping the Tcl error (52 in this case) and then testing the error to see what I want to do.

The 52 means nothing was returned by the URL after the timeout period I think.

By the way, this wouldn’t be the UHC 278 project would it?

You definitely have to use catch around curl::transfer.  There are many reasons that call will fail, server busy being one of them.  You need to put provisions in your code for that.  I asked a question on Clovertech on how to stop an interface and prevent other messages from transmitting while the interface stopped.  This was what I wanted to do if the call failed.

The folloiwng is a link to that post:  <a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=3359&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=3359

Hope this helps,

My situation is a little different.

I have been instructed that if nothing is received after 180 seconds, try one more time and wait for another 180 seconds. If the second timeout fails, then I can stop the thread.

I am using the https protocol with a Tcl proc that does the tclcurl.

What I would like to do is use the timeout setting in the protocol to cause the 180 second timer to kick (I think that is happening) and then I get back the 52 error code.

At that point I want the protocol to follow the timeout path (I have a proc setup to count the number of resends and that works) and all of the other built-in mechanisms of the protocol for message and reply handling. If I shut down the thread the goal is to have the mesage that timed out still in the Recovery DB ready to go when connectivity is next achieved.

Because UHC could not provide a Test environment where I could test a down time situation, I have to wait until Production. Now, of course, we cannot force a down time to check the handling – we have to wait until they have a scheduled downtime.

Complicating matters I am not even sure if the behavior in a ‘normal’ UHC downtime will actually return nothing (I have had instances where I get a string of undocumented text). UHC has a ticket open regarding the behavior I previously experienced.

Thus far I have not been able to get any clarification from UHC as to how their connection behaves in a down time (Production or Test). I will just have to experience it and react.

Moreover, I am begiining to suspect that since UHC actually has multiple layers to their ‘connection’ I may get differing returns depending on what ‘layer’ is actually dow.

There was supposed to be a scheduled down time from 8:00 – 11:00 PM tonight.

Here it is 8:30 and this thing is not down yet!!

If I ever get an opportunity to test this thing and get it functioning I will report back.

Folks,

We have implemented a Tclcurl driver and included a catch that grabs any TCL errors.  Also: illustrates the argument to use to trap errors from the call itself.  Hope this proves useful.

       # do the post in TclCurl

           echo “INFO – $HciConnName – starting HTTPS post – [fmtclock [getclock]]”

           set reply “” ; set err “” ; set headers “”

           if {[catch {curl::transfer -url $url

                          -httpheader $httpheaders

                          -httpauth basic

                          -post 1

                          -postfields $msg

                          -userpwd $userpwd

                          -bodyvar reply

                          -headervar headers

                          -errorbuffer err

                          -sslverifypeer 0

                          -cainfo $cert } tclerr]} {

               echo “ERROR – $HciConnName – $tclerr n $err”

            }

        echo “INFO – $HciConnName – finished HTTPS post – [fmtclock [getclock]]”

        # Check if an error conditon is true from TclCurl action.

        # Note: be careful if you modify the error message text – linefeed and spacing.

        if { (![cequal $err {}])||($tclerr > 0) } {

              set reply “t Hub Status Report from connection n

                         t Cloverleaf protocol error encountered ($context) n

                         t for payor at ($url) n

                         t n

                         t Refer to Hub Support On Call as SEV 3″

        }

You can put in a catch but you must realize what you catch is not necessarily a Tcl error.  curl treats many things as errors

For example in the case cited here curl caught error 52 which is:

“Nothing was returned from the server, and under the circumstances, getting nothing is considered an error”

Would you really want to shut down for that error?  You might want to ask the owners of the server why they periodically return nothing.

Also, instead of the transfer command consider using the configure and perform commands.   Gives you a lot more control.