Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

CR1000 Timeout for HTTPPost?


clong Sep 11, 2015 06:18 AM

I appear to have got a logger stuck in a HTTPPost request by stopping the server it was communicating to as it was posting data. Even though the server is back up, the logger seems to be stuck in the HTTPPost call and I have not heard anything for about 6 or 7 hours.

Is there any way of finding out what the timeout and procedure is for this function?

I had a test rig working which never seemed to mind if I killed the HTTP server, and would catch back up as soon as it became available, however now I have deployed it in the field I've immediately killed it. I think this is just due to very bad timing on my part- stopping the service before the CR1000 had fully disconnected, although I am surprised it has not timed out and continued with the slowsequence.

It looks something like this. Does anybody have any ideas? It's over GPRS, a few hours drive away, so solving remotely would be ideal, but I need to figure out how to stop this happening in future. Where is it stuck?

Here is the SlowSequence:

' Slow sequence to send data from minute table every minute
SlowSequence
' Start up delay...
Delay (1,10,Sec)
' Don't send first time, so set lastMinute to the current minute.
RealTime(rTime(1))
lastMinute = rTime(5)
Do While TRUE
RealTime(rTime(1))
' Reset modem at 2 in the morning.
If rTime(4) = 2 AND rTime(5) > 11 AND rTime(5) < 15 Then
SW12(0)
' If the current minute is not the same as the last minute that data was sent
Else If (rTime(5) <> lastMinute) Then
SW12(1)
If NOT ComPortIsActive (ComRS232) Then
PPP = PPPOpen
Delay (1,2,Sec)
postresult1 = HTTPPost("http://<<ipaddress>>:<<port>>/<<url>>", "datatable1", HttpResponse, "", 1, 0, Min, 32)
postresult2 = HTTPPost("http://<<ipaddress>>:<<port>>/<<url>>", "datatable2", HttpResponse, "", 1, 0, Min, 32)
PPPClose
lastMinute = rTime(5)
EndIf
EndIf
Delay(1,1,Sec)
Loop
EndSequence


JDavis Sep 11, 2015 10:59 PM

The timeout for HTTPPost in on the order of minutes. I don't recall what it is currently.


Your loop is using PPPOpen and PPPClose very frequently. That might be what caused the problem. When possible, I leave PPP open.

From your code, it looks like you have a 1 minute window each hour when PPP stays closed. You could try connecting through the modem in serial server mode when that time comes around. You would have to keep trying to connect, because when the time window is depends on when the program started.


clong Sep 12, 2015 08:07 AM

Thanks for your response.

Can I ask for more details about the HTTPPost timeout?

In my specific case, the CR1000 was able to initiate a connection to the server and send data, but never received a response. Could it be the case that the timeout is only for connections which are never successful? It now seems to be locked in the HTTPPost, with PPPClose never being called, and the SlowSequence permanently stuck.

I think you may have misread my code regarding the 1 minute window- that is designed so that repeated calls to HTTPPost are not made. Because I am using streaming mode this is not actually an issue, but I thought it sensible to go straight to the delay if the minute has not changed- lastMinute is only set when the slowsequence first runs, or when HTTPPost returns and PPP is closed.

The result of this is that ordinarily I can dial in and stay connected over a CSD connection provided the logger is not already in a PPP session. I am not able to do this at the moment which would suggest that the logger still believes itself to be in a PPP session.

I can also request information from the SIM provider about when the modem last registered which will probably prove whether or not the 2am reset occurred to switch the modem off.

There are only two things I can see this being- one is the fact that the modem is connected to the CS I/O port rather than directly to the RS232, or the other, that the operating system was unable to cope with not receiving a response from the server, and the call to HTTPPost has never returned, nor timed out.

I have requested that the logger be rebooted which should solve the problem- but it does mean that I have to be incredibly careful when I do maintenance to the server, not to pull it offline when a HTTPPost transaction may be occuring.

My test rig was set up for many weeks, opening and closing PPP every minute and I didn't have any problems with this- if it had been unreliable I would have changed to a permanent PPP session.

What are your thoughts on this?

Log in or register to post/reply in the forum.