Webdynpro ABAP/Portal. Plugin HTTP connection issue on WaitingEventQueue.js

Question

Hello,
We are experiencing a strange Portal Behavior with our Webdynpros. Our portal contains several iViews including some Webdynpro (ABAP) and some reporting transaction calls that use SAPgui for HTML.
When portal is called for the first time and a user logs in, two connections of type RFC can be seen for that user in SM04 in our ERP system. All iViews work as expected. For example, calling the Time Management webdynpro closes one of the RFC connections and starts a new Pluguin HTTP connection. We can go back and forth between the welcome page and this Webdynpro with no issues.
If we then select one of the reporting transaction codes, the portal launches the SAPGUI for HTML. Report retrieves and shows data, and then we close using the "Exit" button provided by the sapgui for HTML
Next we try again to launch any webdynpro (abap), but SM04 shows that the new Plugin HTTP session gets stuck and spinning mid way, and will stay there. Refreshing the Portal screen with F8, navigating back and forth, logging off and on again has no effect. The webdynpros will not launch again. Only webdynpros are affected, any of the reporting transactions can be called successfully over and over.
We have figured that deleting Temporary Internet files (we are using IE 7), and in particular by just deleting the WaitingEventQueue.js?XXXXXXXXXXX file, the system will break away from the spin loop and show the webdynpro again, but eventually it will get stuck again, and asking the users to delete their Temporary Internet Files every 5 minutes is not a workable solution
I have reviewed the contents of this javascript file at different points during the test, and the contents do not change, so deleting the file and the recreate process must be resetting somehow the queue and allowing for a new correct communication.
Is there a way to properly reset this event queue (for example from ABAP, when the webdynpros are reloaded) in order to avoid the spin loop?
Thanks for any help!
Andres

Answer 1

Well, we got the issue resolved, so here is what we did, in case anybody is interested:
Tested again our portal with multiple versions of Internet Explorer, in particular IE8 and IE6, the Webdynpro behavior was normal (no timeouts or locks). It even worked when we installed IE7 in a brand new machine and tried our portal.
So we started suspecting if maybe the particular IE7 that we install internally (with specific settings and policies) may be the culprit. We took a desktop that was producing the timeouts and used the following options in IE7:
Tools->Internet Options->Advanced(tab)-Reset Internet Explorer settings
and, voila! the next time we ran there, the portal did not create any timeouts.
We even asked our desktop support team to uninstall and reinstall IE7 in the same machine after we did the reset, and even after the re-install that the timeout problems did not re-appear.
One of the things that the "reset" option does is delete the Add-ons used by IE.
So as a last test, we took a machine that was presenting the problem and went to the Internet Options to disable all the add-ons (in the Programs Tab). The error disappeared.
And even after enabling back all the add-ons, the error would not return.
Conclusion:
Without being able to pinpoint the specific add-on (or combination) that causes the problem, we suspect that some of them conflicted, causing IE7 to behave abnormally. Disabling them all, restarting Internet Explorer, and enabling them again, makes the WaitingEventQueue.js work as it should