Issue 377: IndexOutOfBoundsException in ApplyRequestValuesPhase

Question

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=377
I don't seem to be able to add comments to this issue, so I'm putting this here instead. Let me know if I'm being slow and could have commented on the issue.
We've also seen this bug using 1.1_01 on JBoss 3.2.6 and 3.2.8. We haven't tested 1.1_02 yet.
We see it on the live servers every now and then, and I've reproduced it a few times on a dev box by starting a long running query in one action method, then hitting the action link again before the query has completed.
If it helps, I could only reproduce it in IE -- Firefox didn't resubmit the form on the second click so the second request never hit the server.

Answer 1

I've been struggling with this same problem for some time (not in the same environment, though). It's been reported several times and commented on, usually by someone who wants a workaround rather than a fix. There's several workarounds.
To recreate in Firefox: submit a page with a long-running query, then click a link to another page, click a link to come back to the submitted page, then submit the page again.
What I did to workaround was set the id on every component. This was suggested by the vendor when I complained. Now that I've done this the error rarely occurs. Obviously, this is far from ideal. A non-obvious problem I ran into is that f:verbatim calls createUniqueId but doesn't allow you to set the id. Luckily it's easy create a component that works the same as f:verbatim but allows you to set the id. To make sure I'd set the id on every component I extended UIViewRoot, overriding createUniqueId to print out a message.
Another workaround I tried was extending UIViewRoot and synchronizing its methods.
Another one I've seen mentioned is to use JavaScript to disable the form.
I've been thinking of another workaround where I'd implement my own Lifecycle and synchonize on the UIViewRoot for the length of the lifecycle.
I think that multiple submits of a form will cause problems if JSF doesn't ignore subsequent submits for the same request. Maybe JSF could put a requestId on each form and ignore any but the first one received. Application developers shouldn't have to handle this.