SOAP - Problem with separate threads

Dave dave at looktowindward.com
Wed Oct 24 06:38:19 EDT 2007


Hi,

Just thought of something!

I use the post command to send the request to the server. If I get  
the "error previous request
not completed" error, couldn't I just check for for this and re-issue  
the command after a wait?

The code would read something like this:

------------------------------------------------------------------------ 
---------
--
-- LibSoapSendRPCRequest
--
------------------------------------------------------------------------ 
---------
function LibSoapSendRPCRequest  
theSoapID,theSoapAction,theMethod,theHeader,theParams, at theSoapReply
   local mySOAPEnvelope
   local mySoapURL
   local mySoapNameSpace
   local myNameSpaceMethod
   local mySoapResponse
   local myHTTPHeader

   repeat while sgSoapInUseFlag = true
     wait 10 milliseconds with messages
   end repeat
   put true into sgSoapInUseFlag

   --
   --  Get the Session Parameters
   --
   get LibSoapGetSessionParameters 
(theSoapID,mySoapURL,mySOAPEnvelope,mySoapNameSpace)

   --
   --  Substitute the fields in the Prototype Soap Envelope
   --
   put theMethod && "xmlns=" & quote & mySoapNameSpace & quote into  
myNameSpaceMethod

   replace "<$METHOD>" with "<" & myNameSpaceMethod & ">" & cr  in  
mySOAPEnvelope
   replace "</$METHOD>" with "</" & theMethod & ">" in mySOAPEnvelope
   replace "<$PARAMS/>" with theParams in mySOAPEnvelope
   replace "<$HEADER>" with theHeader  in mySOAPEnvelope

   --
   --  Post the Request
   --
   put _LibSoapGetHTTPHeaders(mySOAPEnvelope,mySoapNameSpace & "/" &  
theSoapAction) into myHTTPHeader
   set the HTTPHeaders to myHTTPHeader
   --libUrlSetSSLVerification false

put true into myRetryFlag
repeat while myRetryFlag = true
   try
   put false into myRetryFlag

   post mySOAPEnvelope to url mySoapURL

     --
     -- Catch Time-Out Errors
     --
   catch myError
    if myError = ""error previous request not completed"" then	
      wait 10 milliseconds with messages
  	  put true into myRetryFlag
   	  next repeat
    end if

     answer myError
     breakpoint
     put false into sgSoapInUseFlag
     return mySoapResponse

	 end try

end repeat
	
   --
   --  Retreive Results
   --
   put it into theSoapReply
   put the result into mySoapResponse

   put false into sgSoapInUseFlag
   return mySoapResponse
end LibSoapSendRPCRequest


All the Best
Dave


On 23 Oct 2007, at 17:42, Andre Garzia wrote:

> Dave,
>
> never, ever, use a wait command while network routines may be working.
> The wait call will wreck them. If the problem is entering a race
> condition, like, when one call is being placed, the other can't work.
> This happens because libURL will queue requests to the same server, so
> if you call the same server two times in a row without allowing it to
> deal with the first request, you receive an "error previous request
> not completed".
>
> The idea of using a flag local variable is the best option, but do
> that without the wait call. Work like this, if the flag is true,
> postpone your operation to same later time. like
>
> if isInUseFlag then
>   -- call in use, postpone..
>   send "doTheRequestAgain" to me in 2 secs
> else
>   -- do the request...
>   put false into isInUseFlasg
> end if
>
> The hardest part is making a function that can re-request something
> because if you're using send in time, you can't gather what were the
> original parameters for the call by examining the pendingMessages.
>
> If I were in your shoes, I'd work like this:
>
> 1) create a transaction queue. This would be an array where each web
> request would be a member. Each array member stores all the info
> needed to do a SOAP request.
>
> 2) I'd had a loop that would pick this array and work on the first
> member, after dealing with this member, I'd remove it from the array.
>
> 3) Pooling the server then is just a matter of a simple send in time
> that adds an element to the end of the array.
>
> 4) any function that would force a SOAP request would simply add an
> element to the end of this array.
>
> This way all your requests will work in order without the need of a
> locking mechanism or a wait call. By having a 'callback' stored along
> the data for each array member, you make your code as multi-taksing as
> it can be in Rev.
>
> Since all your calls are on the same place (the array pooling
> function) you will not enter race conditions and your debugging will
> be easier.
>
> People with CS background will recognize this as nothing more than a
> datastructure known as First-in First-Out queue. By making functions
> like:
>
> addToQueue pQueue, pElement -- add Element to Queue at last poisition.
> takeElemFromQueue pQueue -- returns the first Element from queue  
> and removes it.
>
> You have created a generic queue function library that can be worked
> in other projects.
>
> Cheers
> andre
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution



More information about the use-livecode mailing list