Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 253756 - Request retry causes multiple browser-instances error
Summary: Request retry causes multiple browser-instances error
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.2   Edit
Hardware: All All
: P1 critical (vote)
Target Milestone: 1.2 M7   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard: qx-open
Keywords:
Depends on:
Blocks: 273397
  Show dependency tree
 
Reported: 2008-11-04 13:12 EST by Cole Markham CLA
Modified: 2009-05-12 11:10 EDT (History)
2 users (show)

See Also:

Attachments
Detailed analysis of the bug (152.94 KB, application/pdf)
2009-04-21 17:13 EDT, Vasko Tchoumatchenko CLA 		no flags Details
Workaround (2.01 KB, patch)
2009-04-21 17:15 EDT, Vasko Tchoumatchenko CLA 		no flags Details | Diff
An incorrect bug number reference fixed in the comments. (2.01 KB, patch)
2009-04-21 17:20 EDT, Vasko Tchoumatchenko CLA 		ruediger.herrmann: iplog+
Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Cole Markham CLA 2008-11-04 13:12:37 EST 
Build ID: N/A

Steps To Reproduce:
1. Load a RAP application from a remote server (not localhost)
2. Disconnect the network cable
3. Click a button, etc and wait for the retry dialog
4. Reconnect the network cable and wait for the network to reconnect
5. Click retry on the dialog, opens the error dialog with the following message:
"Multiple browser-instances or browser-tabs per session are not supported. You may click OK for restarting the session."


More information:
This also happens if the wireless connection gets dropped but that is more difficult to reproduce.
Comment 1 Cole Markham CLA 2008-11-04 15:43:00 EST 
Digging through the code I can see that the multiple instances error is generated when the requestCounter does not match what the server is expecting. That must be the case here, but it is unclear to me exactly why this would be. It seems that the client is resending the exact request that was previously sent. Is it possible that the client is sending the next item in the request queue before the failed request can be reinserted?
Comment 2 Vasko Tchoumatchenko CLA 2009-04-21 17:13:50 EDT 
Created attachment 132675 [details]
Detailed analysis of the bug

A Qooxdoo bug is opened based on the findings in this analysis:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=2272
Comment 3 Vasko Tchoumatchenko CLA 2009-04-21 17:15:12 EDT 
Created attachment 132676 [details]
Workaround
Comment 4 Vasko Tchoumatchenko CLA 2009-04-21 17:20:15 EDT 
Created attachment 132678 [details]
An incorrect bug number reference fixed in the comments.
Comment 5 Ralf Sternberg CLA 2009-04-23 06:01:12 EDT 
Fixed in CVS HEAD.
Committed the suggested workaround, but left the sending handler in place, as this is needed for normal (non-failure) operation.