I am planning on using AWS and AJAX to dynamically refresh the data on a WEB page without resending the entire page (Connect 9210ME). I have read the document, “The Digi-Geek’s AJAX Workbook”: http://ftp1.digi.com/support/documentation/dynamic_web_pages_with_the_embedded_web_server.pdf
This very well written especially for a newbie and provides a good point for to start. The question I have is in the example in this document the embedded side is “continuously” updating the “RAM0/nnn.xml” document to provide fresh xml data when requested by page. This seems overkill in that mostly the page won’t active. Is there an (easy) way to get a call back only when the url to “RAM0/nnn.xml” is requested? The file could be constructed in the call back only as necessary. I would also like to keep AWS doing most of the work serving pages without doing a complete CGI implementation. So only a callback for this xml file request, not all other pages.
Any pointers or reference to the applicable API would be appreciated.
To continue on this issue. I have been doing some testing with a setup basically the same as the example in the above referenced document. There are two issues I have encountered and wonder if there is a workaround:
1 - I have the XML file being refreshed in a thread about every 10 seconds. The Java Script on the WEB page pulls this data with an XMLHttpRequest about every 1/2 second. Every so often the refresh thread fails to open the file with a error code 23, (Too many open files in system). I assume this is because there is a collision and the Http request is being serviced at the same time the refresh thread attempts to open the file.(?) This I can live with because the next attempt to refresh the file works. However it would be nice to fix this.
2 - This problem is more serious; if I keep switching between the AJAX page and other (static) pages eventually the above error occurs. However in this case no recover is possible and the entire WEB site locks up. I “assume” that because I am switching pages the AWS thread servicing the XMLHttpRequest prematurely exits leaving an open file descriptor.(?) Has anyone seen or know how to handle this scenario?
So getting back to the original post I think if I had a callback just for the XMLHttpRequest I could handle the file management. Should I even be using the AJAX method described in the document above? It seems nice and simple and works well when just sitting on a single page.
Any help with this is greatly appreciated.
BTW, using latest NET+OS with all packages updates.
I set up the JS to request a ‘standard’ web page, which then goes through the normal AWS route, with data being assembled dynamically on each page request (rather than updating a file whether needed or not).
Note that the format of the data returned in this page request is entirely up to you; there is no need to use an XML or html format if you don’t want to. But obviously the JS in the browser has to be able to decode whatever you send. I used a simple plain text data format, one variable per line.
(This has been working with no apparent problems for years!)
Thanks for your response but that is not the issue I am having. I realize that different return formats can be parsed by the JS. My issue is I have two threads competing for access to the data file (regardless of format). The producer is a thread of my own, updating the dynamic data, basically voltages. The consumer being the WEB Page through the XMLHttpRequest. At times I believe these “collide” and the producer thread is unable to open the file to refresh the data. This clears itself on the next time around. The more serious issue is that if I switch between pages frequently by clicking page links I can very quickly lock up the site and the producer thread will hereafter not be able to open the file for refresh. Of course my theory on this could be way off, I simply followed the example in the referenced document.
Actually to be more accurate to my original post, I didn’t want to have the producer thread updating the XML file “all the time” as the WEB page/site will be used infrequently. This was really just an efficiency concern, however I could live with that. Subsequent to the first post, my testing turned up the two problems in my second post, one of which would be a show-stopper. Sorry if I changed the subject on you.
Well I am back on this issue. I was on the wrong path, it is not related to one thread updating the XML file when the XMLHttpRequest is received by the http thread. I changed the test so that the XML file is only created once at startup. I can then go to the page that performs the XMLHttpRequest and the page will continue to get the XML file and update the page elements as expected. The failure occurs when I repeatedly and quickly switch between other pages and the AJAX type page. The system will eventually “lock up”. Further debug showed that the system keeps getting called back into the RpHSOpenFileStatus(…) function in the /sys/http/file.c module.
Has anyone seen this behavior and know what I am doing wrong? I would hate to throw in the towel on AJAX for dynamic refresh as it is clearly more elegant than refreshing the entire page. Has anyone beat up the pages like I am doing by rapidly clicking between pages?
Thanks in advance.
For anyone that might be interested I have “solved” my problem.
Although I was not able to get the system to act reliably when using a file located at /RAM0/myfile.xml
I followed the reference document exactly:
“The Digi-Geek’s AJAX Workbook”
This implementation works fine if one just sits on the page, however if you stress the system by rapidly
switching WEB pages it will eventually hang up in the callback RpHSOpenFileStatus(…) or another file callback.
You can increase the likelyhood of failure by decreasing the time between xml file fetches in the Java script code.
So unless someone clues me in to what I am doing wrong I cannot endorse the reference document entirely.
However it is well written and a good starting point for AJAX on Advanced Web Server.
So my solution was to use the CGI callback for the XML data sent back via the XMLHttpRequest.
For this you can look at the document:
“Developing CGI-based AWS Applications Using Digi’s NET+OS Development Environment”
You simply modify the file [YOUR PROJECT PATH]\sys\http\cgi.c
The function, RpExternalCgi(…), in this file gets called whenever the requested URL cannot be found.
In this case the xml document.
Modify this function to check that if the URL is one that you want to trap on.
Fill a buffer(s) with the xml data and return.
The following should be filled in before returning from the function.
theCgiPtr->fDataType = eRpDataTypeXml;
theCgiPtr->fResponseState = eRpCgiLastBuffer;
theCgiPtr->fHttpResponse = eRpCgiHttpOk;
theCgiPtr->fResponseBufferPtr = YOUR_XML_DATA_BUFFER;
theCgiPtr->fResponseBufferLength = strlen(YOUR_XML_DATA_BUFFER);
In my case the data fit in a single return buffer otherwise you need to send it back in multiple
calls and modify theCgiPtr->fResponseState accordingly (I did not experiment with this).
Another plus with this method is the xml data is only updated when data is requested whereas “geeks guide” suggests
updating the RAM file periodically in it’s own thread.
It is also easier to add any data MUTEXes or thread syncronizations that may be required with this implementation.
I hopes this helps someone and if not it will be a future reminder for myself.
Again if anyone knows how to get “Geeks Guide” implementation working reliably let me know.