oXML=CREATEOBJECT("msxml2.xmlhttp.3.0")

[FoxAll]

Hi Foxpro Expert,

I have a strange bug, I need to find the cause or find a workaround solution.

here it is:

On my server, windows sbs 2011 is intalled. I run nine(9) VFP9 programs compiled in EXE. One the the program doing just 1 thing: send XML. The program send XML several time during the day to lot of different IP address.

The problem is:
If the program sending XML freeze (I don't know why it's freezing?).... ALL foxpro application also freeze (NOT RESPONDING) and are not accessible. It's like the object create in foxpro LOCK foxpro main core. The CPU activity drop to 0%. After 10 to 20sec. everything return to normal like nothing happen. And all fox pro application continue to work.

When I go to Event viewer ... nothing correspond to the time the problem occurred. And I don't see any error in there.

Other program than foxpro running just ok. So, last time it was doing that, I take a screen shot to show you the RESOURCE MONITOR.

Please take a look

http://www.instaweb.biz/images/bug.gif

here is the code causing this

oXML=CREATEOBJECT("msxml2.xmlhttp.3.0")
lcLink = "[URL unfurl="true"]http://xxx.xxx.xxx.xxx:7007/cgi-bin/abc_tt.cgi"[/URL]		
oXML.Open("POST", lcLink , .f., "user", "pwd")
lcResult = oXML.Send(lcXML)

Do you know How i can isolate the xml transmission to never freeze or interfering with other foxpro exe?

thank you for you time and help

 

[GriffMG]

I have a scanning program that sends emails sometimes, if the message is really large (> 100MB) it would
virtually hang the server - particularly if the recipient email address was bad (i.e. had no @ in it!).

What I did was made the program reload a new copy of itself and exit the original copy (leaving the newly loaded on the continue)
after a fixed number of iterations (say 8 or 2000 your choice). This has been running for a couple of years without issue.




Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

I would look into Task Manager into the Process tab and inspect the threads of all the VFP9 exes and especially look for the vfp9r.dll. Seems all your exes share one instance of it. Put every of your exe in a seperate folder and add a vfp9r.dll inside each of these folders, that should make them load that dll multiple times into memory, making all the processe independant on each other.

It's worth a try, even though that wouldn't explain vfp9.exe not responding, as vfp9.exe is not using the vfp9r.dll at all.

The other limiting factor might bei the high network traffic, which could put all your exes into waiting states.

You also run FoxWeb several times, is each exe related to Fox Web?

Bye, Olaf.

 

[FoxAll]

Excellent suggestion,

It is already in a different folder so i'm gonna try to copy vfp9r.dll in each folder to see if this can make a difference.

About the network activity, it's a mapped drive, one of the exe scan a DBF file on another machine. This is base on a timer. Maybe it's causing a network problem when the XML hang.

This problem is intermittent, it's happen 2 or 3 times a day and it's not longer than 15sec. But it cause me problem on other exe that recieve "Winsock UDP" transmission.

I understand the problem is complex and only few people can figure it out.
Thanks again for your suggestion.
I will try it.

 

[Olaf Doschke]

What's happening besides the 9 foxpro apps is perhaps also of interes. Is it happening at the same time each day? Is there perhaps a scheduled task involved? something copying via LAN, a backup job?

You're right, you will only figure out what's the reason within the system.

Bye, Olaf.

 

[FoxAll]

Ok,

When I changed my "Asynchronous flag" to .TRUE. then the execution take 0.001 sec. to send XML, instead of 3.6 sec.

I also do not have any more server lock with this setting so it's very very good. I think the solution is right there. But, It cause another problem. The XML send is so quick, I cannot catch the response.

QUESTION: Is there a way in foxpro to use OnReadyState to get back the result when it's ready ?

Like we do in AJAX? is it possible to do it with BINDEVENT( ) or any other way?

Can you help me?

Thank you

 

[Olaf Doschke]

Well, it's not really quicker, it's just asynchronous, program execution doesn't wat for neither the end of the send nor the response.

You can't subclass OCXes or COM classes in VFP, but you can define an eventhandler via IMPLEMENTS clause of DEFINE CLASS. You need to find out wht interface msxml2.xmlhttp.3.0 inherits to make use of it. I have to investigate further.

What I did is polling readystate in a timer, which was sufficient for me and is much easier to implement. Using a timer managing a collection property storing all the msxml2.xmlhttp.3.0 objects added to it and if they turn to readystate run a method as "callback".

Define Class RequestTimer As Timer
   Enabled   = .T.
   Interval  = 250
   * temporarily store Requests until their Readystate turns to 4 (cnReadyStateComplete).
   oRequests = .NULL.
   
   Procedure Init()
       This.oRequests = Createobject("Collection")
   EndProc 
   
   Procedure Timer()
      This.Enabled = .F.
      * poll for Requests with ReadyState=cnReadyStateComplete
      Local lnCount, loRequest

      For lnCount = This.oRequests.Count To 1 Step -1
         loRequest = This.oRequests.Item(lnCount)
         If loRequest.ReadyState = cnReadyStateComplete
            =Evaluate('loRequest.oClient.'+loRequest.cCallback+'(loRequest)')
            This.oRequests.Remove(lnCount)
         Endif
      Endfor

      This.Enabled = .T.
   Endproc

   Procedure AddRequest()
      Lparameters toRequest
      This.oRequests.Add(toRequest)
   Endproc

   Procedure DisposeRequests()
      Local lnCount, loRequest
      For lnCount = This.oRequests.Count To 1 Step -1
         loRequest = This.oRequests.Item(lnCount)
         loRequest.Abort()
         This.oRequests.Remove(lnCount)
      Endfor
   Endproc

   Procedure Destroy()
      If Vartype(This.oRequests)='O'
         This.DisposeRequests()
      Endif
   Endproc
Enddefine

The toRequest parameter of AddRequest needs to be prepared as follows:

loRequest = Createobject('MsXml2.XmlHttp')
ComProp(loRequest,'UTF8',1)
AddProperty(loRequest,'oClient',oClient)
AddProperty(loRequest,'cCallback',"ProcessResponse")

In which oClient is the object handling the response (which could be THIS in many cases) which needs to have a method "ProcessResponse" (or whatever you call it), which needs to have a parameter toRequest. So oClient.Processrequest(oRequest) is executred, when the timer event detects a readystate of 4. That method than receives the request object, when it's response arrived with a time lag of half the timer interval in average. This was close enough for me and still allows parallel execution of several requests, if they don't need any info coming back from a response of another request.

Bye, Olaf.

 

[Olaf Doschke]

Oh, and of course you also call the OPEN() or SEND() of the loRequest asynchronously, beore you call into oTimer.AddRequest(loRequest) and let the timer do the waiting for the response.

Bye, Olaf.

 

[Olaf Doschke]

...and oTimer of course would be created as oTimer = CreateObject('RequestTimer'), better yet as _Screen.Addobject('oRequestTimer','RequestTimer') to be available throughout the app.

Bye, Olaf.

 

[FoxAll]

wow, Impressive!

I will try that.

Thank you

 

[Olaf Doschke]

ONe ingredient is missing, still:

#DEFINE cnReadyStateComplete 4

Maybe you guessed it already. It was way above the class definition and therefore forgotten, Sorry.

Bye, Olaf.