Browser hangs after sale ; scale reader ajax is locking up php execute

[1robert]

When the is4c lane scale reader is on it somehow stops the php execute function from synchronising the lane database with fannie. This causes php to hang. The server must be restarted to get things going again.

This happens with firefox and chrome on winxp mysql5 and two different machines one running php5 and the other php4
This effect does not happen with IE because the ajax code in is4c doesnt work with IE.
the ajax scale reader is in chscale.php

I cant imagine how this happens but it is quite weird.
If you put an invalid file name into the argument for the listen function in the ajax code, it all runs ok except of course there is no scale readout!!!

I have also removed the ?rand=randno.99999 from the request to the scale file and there is no difference in operation. The scale writes to this file so I cannot see what use this query is.

[jdpurdyvi]

I can try to figure out if this is still the case, but the rand string was appended to the scale request in an effort to prevent the browser from caching results.

[lgedgar]

@!#!? No comment previews, huh? Not a fan of that.

Found myself with little to do and a strange desire to tackle this problem tonight. I've discovered at least some of the problem(s) with the current code for Windows. Of course, I imagine Andy@WFC has found and fixed these bugs long ago...

I think the main problem is that the listen() function (in chkscale.php) starts AJAX requests for the file rs232/scale every 70 ms, as stated earlier (at http://www.wedge.coop/is4c/bb/viewtopic.php?p=539#539), and each time it checks the responseText to see if it equals "ok" - but the only thing I could find in the source tree that would ever change the contents of that file is the ssd scale driver, which I believe is known to work only for Linux. So in essence there is an infinite loop...

I've forked this project and committed some changes to that branch (in particular see http://github.com/lgedgar/IS4C/commit/897a9c235d441e479538075395f80998e3aa0407), but if you really want to get past this I'd suggest simply commenting-out the listen() call and looking around for a Windows scale driver solution...again I think Andy has dealt with this long ago so you might start at http://code.google.com/p/is4c-fannie/.

[lgedgar]

On second thought my above comments aren't quite right. I still don't have it really figured out, but looking at scale.php it seems as though the value "ok" should never in fact come from the rs232/scale file. So...I don't know why the "ok" check is even there, but its failure isn't why there is an infinite loop. I believe the loop is infinite on purpose (makes sense if polling the scale should always be happening), so that's not the problem.

[1robert]

Well I have spent some more time pondering and investigating this issue.
Consider this:
If you create a file called scale.txt and type in 1.2kg ::
which is what scale.php prints out, then change the url in the javascript to scale.txt, guess what?
php does not hang, but of course the scale is static.

Another thing if you only let the listen function run once or stop it before finalising the sale all goes ok.

Somehow the looping through the php processor is causing it some problem, which I have yet to find anything about.
Except some javascript tutorials which state that js is one threaded and so can only do one thing at a time. So trying to pause the script with setInterval() or setTimeout apparently stops any process of httpRequest.

I must point out that the scale reader is doing its job nicely, any change of input into rs232/scale is immediately displayed on the screen. so if S11123 is typed into rs232/scale the screen displays 1.23Kg (in oz we are metric)

[maxolasersquad]

I wonder if we reprogrammed the daemon to print 0.0kg to the file when no data is found, if that would fix the problem.

[1robert]

I have spent many days looking further into this.
First I renamed chscale.php to chscale.htm, it doesn't need to be a php file and so reduces the demand on the php server.

2 I have experimented with a "killscale" switch which switches the ajax over to reading a text file with a single line 0.00kg:: ::1
instead of scale.php
The chkscale.htm reads this and thinks it is reading a scale value but in this case no php calls are made. So far this is working.

You cannot just turn off the scale reader because how do you start it up again without refreshing the scale frame or the whole page without using some clumsy code?

Also chkscanner.php is also running and all this adds up to a large server load.
I checked my apache acccess logs and it was hundreds of megabytes after a few days.

every ajax request is recorded.
This looks like an example of push polling the server and it is likely that this is causing the server to have problems.

My apache config file states that it starts with 250 threads. In the error log it indicates it has often used them all up.

So the upshot is

I have reduced the polling rate to 500-1000 milliseconds which helps, and also the scale meter still works

There are two options turn off the scanner and scale ajax requests before using php(exec)
or use a more mundane way of synchronising the lane and master databases.

robert

[maxolasersquad]

1robert: I finally got around to looking into this issue as we are experiencing the same problem when we use Chrome, but not in Firefox. I have found that setting the setTimeout in chkscale.php to 500 makes it usable for us. I think you are right on about removing the .php extension so that it doesn't go through the php engine. I'll update this soon.
I'm sort of confused as to why Firefox on Ubuntu doesn't have any issue and Chrome does. I hope to do some more research on this and find a long term solution.