Premise Gargantuan Bug in MiniBrowser.

[123]

After spending a lot of time revising the MiniBrowser module, I encountered, on many occasions, what appeared to be a random bug. Well it is not random and it can be reproduced. It is a nasty one and it imposes an unwelcome limitation. This problem is also evident in all modules derived from MiniBrowser like the xBrowser and iPhone modules.

Here's how it manifests itself:

• Run http://locahost/ppc. This start a Web Session that relies on the MiniBrowser module.
• After successfully navigating through several links (probably more than a dozen), you'll click one (it can be any link) and the browser sits and waits for a response that never arrives. The only remedy is to close the browser window and start again with a new browser window (i.e. start a fresh Web Session).

Here's what I've discovered:

• Premise's web server appears to be limited to handling approximately ten concurrent Web Requests.
• When you start a Web Session it will generate one Web Request for each Location object.
• Each time you toggle a light's Power button, it generates a new Web Request.
• After it reaches ten unique requests it ignores all others. I don't know how to increase or eliminate this threshold.

Here's how to see this problem for yourself:

1. In Builder, navigate to WebServer > Sites > Default Web Site
2. In the Properties window, enable the Debug property.
3. Navigate to WebServer > Sites > Default Web Site > Requests
4. Open Internet Explorer and run http://localhost/ppc (or http://localhost:86/ppc)
5. You'll notice that the Requests folder now has a few Web Requests (if not, ensure Debug is enabled and restart Premise Server).
6. Click a few links in the browser and watch what generates more Web Requests.
7. Toggling a light's Power button will generate Web Requests.
8. After ten Web Requests are logged, all subsequent requests are ignored.

I have not found a way of eliminating this problem. However, I know how to mitigate it so that you can get in a few more clicks before reaching the 'Web Request limit'. Basically, many links are generated with a unique identifier that changes each time the link is rendered. By eliminating this unique identifier, URLs look like this:

http://localhost:86/sys/%7B38DDEFB2-4FFC-4100-AAE1-067F0484895F%7D?d??mbTogglePower

instead of this:

http://localhost:86/sys/%7B38DDEFB2-4FFC-4100-AAE1-067F0484895F%7D?d??mbTogglePower(ID794E6B36265E4888B872929A43C523B1)

and, for the most part, do not generate a unique Web Request each time the Power button is clicked. So far, I haven't seen any downside to eliminating the unique identifier.

I'm really surprised no one has ever noticed this problem. The only explanation is that few people use the web-interfaces rendered by MiniBrowser/xBrowser/iPhone and, when they do, they do not use them extensively (i.e. just a few clicks).

Is Jim still around? Maybe he can shed some light on what, if anything, can be done about this problem. Perhaps there's a way to increase the Request limit and have the Requests expire promptly or some way of coding the URLs so that they don't generate so many unique requests.

PS
AutomationBrowser does not have this limitation and appears to work differently. Start http://localhost and you'll get eleven Web Requests where the eleventh one is for SYSConnector. Click away to your heart's content and the number of Web Requests remains unchanged.

 

[chucklyons]

hmmm...I just tried it and found a couple of things, one of which may explain why I haven't seen it. I gave it a quick run thru, banging the Power property on the light, from IE. It did exactly as you observed; it 'hung' after ten requests. I then did another quick run, and didn't have the problem. The difference? I use Firefox (or Safari) for my day to day xb/ppc/iphone usage and couldn't recreate it during this short test using Firefox. (not a conclusive test by any stretch)

Having said all of that, I can't run a more thorough test, as I am RDP'd in from Hawaii , but using Firefox, I'm not having the problem. I just flipped back over to my RDP session and just saw some of the requests timeout from the Firefox session started from my laptop in Hawaii, and disappear. The localhost requests are still there. Using my localhost session running ON my laptop, same result with Firefox. No issue.

A potential clue during my IE test may be the following SYS script engine error from my active SYS server running at home (don't ask me how and I haven't been able to recreate it):

TransactionClose called but no transaction recorded. Did you import a file that has trace flags set?

I don't typically send Morse code messages using my RadioRa lights, but having banged on the iPhone interface thru 20-some taps on the power property, it doesn't seem to be an issue for me.

I'll test more when I get back from Hawaii...

 

[chucklyons]

I'm really surprised no one has ever noticed this problem. The only explanation is that few people use the web-interfaces rendered by MiniBrowser/xBrowser/iPhone and, when they do, they do not use them extensively (i.e. just a few clicks).

Quite frankly, it wasn't until my wife purchased an iPhone that I even used the xb/ppc/etc for more than a casual click here and there. And now that it does work, and my wife DOES use it, I have started focusing my energies on that interface and the functionality that is missing. Like Component control, Zone Availability, etc

 

[123]

Hawaii.
It's a balmy 14F in Montreal today.
'nuf said.

Thanks for opening my eyes to the possibility that the browser plays a part in this problem. I just replayed the experiment using Google Chrome and it never opened more than four concurrent Web Requests. I clicked away at dozens of links (using the PocketPC interface) and it never failed.

I tried using IE8 in Compatibility Mode and it did not improve anything. The only new thing I learned is that the limitation of ten concurrent Web Requests is per Web Session and not per web server. With Chrome and IE8 running at the same time, I had thirteen concurrent Web Requests open in Premise's web server. Three were for Chrome and ten for IE8 ... which had hung. This also explains why I could not reproduce this bug using my 3COM Audrey's ancient web browser (QNX Voyager)!

I wonder what, if anything, can be adjusted in IE8 so it doesn't open so many concurrent Web Requests? EDIT: It just dawned on me that this may not be IE's fault. Maybe Premise's web server is hard-coded to handle IE differently because it normally uses the SYSConnector with IE. Just a shot in the dark ...

BTW
Overall, this is good news. This bug needed a fix or a workaround before I could release MiniBrowser V2.

 

[Waynedb]

I just tried this, locks using IE7 after toggling light on and off, I tried again with Firefox and toggled the light on and off about 30 times without locking.

 

[123]

... locks using IE7 ... tried again with Firefox ... without locking.

Thanks Wayne!

Patient: Doctor! Oy gevalt! MiniBrowser crashes when I use IE!
Doctor: So, don't use IE!