empty reply from server – using curl

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf empty reply from server – using curl

  • Creator
  • #51411
    Lawrence Williams

    We have a process that is crashing a couple times a week and we get the following in the logfile:

    * Empty reply from server

    * Connection #0 to host aix-dbprod3.ochsner.org left intact

    * Closing connection #0

    [pd  :pdtd:ERR /0:        HDW_S:12/07/2009 23:06:35] Tcl error:

           msgId   = message0

           proc    = ‘hdw_cURL_httpQuery’

           args    = ”

           result  = ’52’

           errorInfo: ‘


       while executing

    “error $result”

       (procedure “curl::transfer” line 50)

       invoked from within

    “curl::transfer  -url $url  -post 1  -postfields $msg  -httpheader $headerList  -header 1  -verbose 1  -errorbuffer errorMsg

    -bodyvar httpBody”

       (“run” arm line 36)

       invoked from within

    “switch -exact — $mode {

           start {

               return “”


           time {

               # Nothing to to


           run {


       (procedure “hdw_cURL_httpQuery” line 5)

       invoked from within

    “hdw_cURL_httpQuery {MSGID message0} {CONTEXT httpc_query} {ARGS {}} {MODE run} {VERSION 3.0}”‘

    [dbi :dbi :ERR /0:        HDW_S:12/07/2009 23:06:35] [0.0.40002243] dbiWriteLogMsg: mid exists

    [ssl :clse:WARN/0:        HDW_S:12/07/2009 23:06:35] [0.0.40002243] Cannot keep original OB message interp (yet)

    PANIC: “0”

    PANIC: Calling “pti” for thread hdw_cmd

    Scheduler State

Viewing 9 reply threads
  • Author
    • #70177
      Jim Kosloskey

      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.

      email: jim.kosloskey@jim-kosloskey.com

    • #70178
      Jim Kosloskey

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

      email: jim.kosloskey@jim-kosloskey.com

    • #70179
      Lawrence Williams

      No, this isn’t UHC 278.

    • #70180
      Robert Milfajt

      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="http://clovertech.infor.com/viewtopic.php?t=3359&#8243; class=”bbcode_url”>http://clovertech.infor.com/viewtopic.php?t=3359

      Hope this helps,

      Robert Milfajt
      Northwestern Medicine
      Chicago, IL

    • #70181
      Jim Kosloskey

      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.

      email: jim.kosloskey@jim-kosloskey.com

    • #70182
      Bob Richardson


      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″


    • #70183
      Charlie Bursell

      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.

    • #70184
      Lawrence Williams

      Thank you for all your assistance.

      We originally tried the curl procedures posted on this forum, which use the configure and perform commands…but we could not get it to work until we used the transfer command.  I realize the root cause is probably on the receiving server’s side, but this is another instance of this never happening before using cURL.

      We are asking the dba’s and sys admins about what could potentially be causing this, such as a backup or database issue.  I’ll update this post when/if I have more information.

    • #70185
      Lawrence Williams

      This has now gone from a ‘minor’ problem to a major problem, it ended up causing us to reboot the Cloverleaf server early this morning.  

      Here is a synopsis of what happened:

      Because of the process going into a panic and crashing, an alert was setup to restart the process if it was down for longer than 3 minutes, it was set to do this restart a maximum of 6 times.  This worked well through the weekend, but for some reason late last night it seemed to get into some sort of loop whereby it never corrected itself and in turn backed up an associated process in another site that receives a high volume of messages via SNA, which in turn caused semaphore errors that could not be fixed by any other means but a reboot.  

      Should I open another ticket in reference to this http-client problem ?

      I have requested FTP access for 5.7 REV1, but I have not received anything yet…..  could that have any impact with this issue ??

      Note:   cURL may give new control to these types of interfaces, so far it has been a major pain for us……..

    • #70186
      Lawrence Williams

      update:  I was able to get the REV1 patch downloaded… I just had to call the tech support and request ftp server access for the patch.

Viewing 9 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
Topic Tags