You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Gerhard Petracek (JIRA)" <de...@myfaces.apache.org> on 2008/04/22 22:37:24 UTC
[jira] Created: (TRINIDAD-1053) page blocking during request
processing
page blocking during request processing
---------------------------------------
Key: TRINIDAD-1053
URL: https://issues.apache.org/jira/browse/TRINIDAD-1053
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.8-core, 1.2.8-core
Reporter: Gerhard Petracek
it is possible to trigger multiple requests.
there are more affected versions, but different behaviours -> i just describe the details of 1.x.8-SNAPSHOT:
with 1.x.8-SNAPSHOT the situation is a bit better. however, there are still several issues.
these issues occur at least with ie and firefox, however, they behave differently.
ppr request + ppr requests:
after a ppr request is triggered and during it's server-side execution it is possible to trigger (at least) another ppr request (it depends on the browser).
the next ppr request can be triggered before the previous one finished, but it gets executed after the previous one was finished.
ppr request + conventional/"none-ppr" requests:
a none-ppr request gets executed even though a ppr request is still in progress.
if this is the desired behaviour, there should be at least a web.xml parameter for a "strict" mode.
none-ppr request + none-ppr requests:
with ie it is possible to trigger requests "concurrently" (concurrent execution on the server).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1053) page blocking during request
processing
Posted by "Daniel Niklas (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876192#action_12876192 ]
Daniel Niklas commented on TRINIDAD-1053:
-----------------------------------------
We have had al lot of problems here, too. We decided to overide the existing mechanism of trinidad. Therefor we're using the blockUI-plugin (jquery, http://jquery.malsup.com/block/). It is working like a charm! To be sure, that there are no concurrent requests, we are checking this on server side, too.
There was one problem left: you could do concurrent requests in combination with PPR and <tr:selectOneChoice>, because you can't get the full control of HTML select-elements. Because of that, we have written our own Renderer for this component. After this enhancement, no more concurrent requests were noticed!
> page blocking during request processing
> ---------------------------------------
>
> Key: TRINIDAD-1053
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1053
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.0.8-core, 1.2.8-core
> Reporter: Gerhard Petracek
>
> it is possible to trigger multiple requests.
> there are more affected versions, but different behaviours -> i just describe the details of 1.x.8-SNAPSHOT:
> with 1.x.8-SNAPSHOT the situation is a bit better. however, there are still several issues.
> these issues occur at least with ie and firefox, however, they behave differently.
> ppr request + ppr requests:
> after a ppr request is triggered and during it's server-side execution it is possible to trigger (at least) another ppr request (it depends on the browser).
> the next ppr request can be triggered before the previous one finished, but it gets executed after the previous one was finished.
> ppr request + conventional/"none-ppr" requests:
> a none-ppr request gets executed even though a ppr request is still in progress.
> if this is the desired behaviour, there should be at least a web.xml parameter for a "strict" mode.
> none-ppr request + none-ppr requests:
> with ie it is possible to trigger requests "concurrently" (concurrent execution on the server).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1053) page blocking during request
processing
Posted by "Gerhard Petracek (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591435#action_12591435 ]
Gerhard Petracek commented on TRINIDAD-1053:
--------------------------------------------
wouldn't it be better to change the whole mechanism?
is there a reason why the page isn't locked directly at the beginning of submitForm and _autoSubmit?
what's about the possibility to display a blocking div (see lightweight dialogs).
we could reuse some parts of the existing source code and the div is skinnable.
> page blocking during request processing
> ---------------------------------------
>
> Key: TRINIDAD-1053
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1053
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.0.8-core, 1.2.8-core
> Reporter: Gerhard Petracek
>
> it is possible to trigger multiple requests.
> there are more affected versions, but different behaviours -> i just describe the details of 1.x.8-SNAPSHOT:
> with 1.x.8-SNAPSHOT the situation is a bit better. however, there are still several issues.
> these issues occur at least with ie and firefox, however, they behave differently.
> ppr request + ppr requests:
> after a ppr request is triggered and during it's server-side execution it is possible to trigger (at least) another ppr request (it depends on the browser).
> the next ppr request can be triggered before the previous one finished, but it gets executed after the previous one was finished.
> ppr request + conventional/"none-ppr" requests:
> a none-ppr request gets executed even though a ppr request is still in progress.
> if this is the desired behaviour, there should be at least a web.xml parameter for a "strict" mode.
> none-ppr request + none-ppr requests:
> with ie it is possible to trigger requests "concurrently" (concurrent execution on the server).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.