If I load a JSF page and do not click anywhere for a few minutes and then try to execute any Ajax action, the page stucks and the Ajax status indicator keep spinning forever.
If I reload the page and try to execute the very same action, everything works great.
I'm using JSF with Primefaces and this behaviour reproduces on all my webapp's pages.
Related
My web app is built on spring boot + spring security + JSF 2.2.12
I have read a lot of posts about the view expired exception, and try to solve it using this proposal.
To be shortly, I have added ?faces-redirect=true to my action methods, added NoCacheFilter to inform browser not cache the dynamic JSF pages. Also I have add expired.xhtml page. Also, I have added custom InvalidSessionStrategy implementation using this sample.
For the case, when I have two tabs in my browser, and perform log out in one tab, and in other I click <p:commandButton which trigger POST request for page navigation, everything works fine, browser redirect me to the login page.
But for case, when I have two tabs in my browser, and in one tab I perform log out and then log in, and in other I click again <p:commandButton, the ViewExpiredException is thrown.
Please, help me to solve this issue. Or tell me what I have missed?
I'm getting BusyConversationException while navigating through pages in my jsf project. This mostly happens if the user tries to navigate to another page during an ajax call. This also happens when the user clicks on a link right after clicking on another link without waiting for loading of the page.
For example if the user clicks on more than one link which are generated through a code similar to below one we definitely get this exception. Another example is, lets say the user enter a query on a text field, and our application make an ajax call for searching this query. During that query if the user click on some button to navigate to another page BusyConversationException occurs too.
<h:commandLink value="#{theProfile.profileName}"
title="#{theProfile.profileName}"
action="#{profileBean.aProfileSelected}">
<f:setPropertyActionListener target="#{currentProfileWebBean.theProfile}" value="#{theProfile}"/>
</h:commandLink>
I can catch this type of exception in an ExceptionHandler class which extends ExceptionHandlerWrapper class but I can't save my current state and the best I can do for this case is to redirect to main page when this exception occurs.
Is there any solution for avoiding this? Thanks in advance for answers and comments.
As mentioned in the other answers, this happens if an ajax request is still being processed or if an ajax event is triggered prior to the actual click on the submitting commandLink or commandButton (for instance by a change event on an input field).
Therfore it is not possible to avoid BusyConversationExceptions with onclick="preventEventPropagation(event)";, since the AJAX events are not triggered via propagation.
The issue can easily be avoided by listening for running ajax requests and blocking submits until the pending ajax events have been completed.
The issue and solution are explained in more detail in this blog post JSF2 AJAX/Submit conversation issue.
i found this,
Indicates that the container has rejected a request because a concurrent request is associated with the same conversation context.
The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type BusyConversationException from the restore view phase of the JSF lifecycle.
refer here
I've been seeing this occasionally too. I'm starting to think it's a good idea to put some effort into serializing access to conversations:
Avoid propagating the conversation ID (cid) when you don't need that conversation instance for the target view. Specifically, unrelated navigation links/buttons should suppress the cid parameter (haven't thought about exactly how to do that)
When starting a request that uses an active conversation, disable other UI elements that propagate the conversation and could therefore cause concurrent access. The PrimeFaces or (even better) PrimeFaces Extensions blockUI components work well as a translucent overlay, along with a PrimeFaces p:ajaxStatus to show the busy status.
Begin conversations as late as possible. This will minimize the cases where a long-running conversation would be propagated.
I don't think that any of this is a complete solution, though. As soon as the cid ends up in the location bar (which happens when you do a non-ajax post back of a form when a conversation is active), you potentially lose control over the timing of access to that conversation due to multiple tabs/windows, bookmarks, etc.
I also faced the same problem, when I used to click the .
I have read in one of the book, busyConevrsation happens with that event two actions are happening, so they said use : onclick="preventEventPropagation(event)"; in commandLink to prevent the event propagation for that click. So I have used the same and it's working for me.
So now am not getting the BusyConversationException :)
I have a number of pages with custom harepoint visual web parts. In the page load of these web parts, i am doing some logic which i need to trigger every time the page loads. the problem is that when i use the browser back button, or javascript, to redirect the user to the previous page, the pageload is not being invoked. it seems like the page is being retrieved from a cache. can this be disabled easily? is there any other workaround to ensure that the code fires every time the page is rendered?
Using the back button will load from cache, you are correct in that.
To disable cache, you need to set an "expires" = -1 meta tag in the head section of the page but this seems a bit drastic in order to fire logic for a page.
I'd suggest using the jQuery document ready approach rather than page load. This will fire regardless of where the page information is loaded from.
$(document).ready(function() {
// Insert code here
});
I am having a richfaces app where pages would show a modal panel with a "Pls wait" message whenever some ajax processing is done. This works fine in IE and Firefox if used in separate web apps, but when I try to embed one web app into another webapp(like portals) and do the processing, it works only until a point where only ajax calls are submitted from the page. The moment a non-ajax call is invoked, the modal panel doesnt appear on the screen until screen refresh using F5. Specially this happens only in IE and works fine in FFox.
I am using webSphere portal 6.1. I wrote my own custom login portlet and placed in the Login page from the portal server. The page loads fine the problem is when I try to login. It takes 2 attempts to login. The first time when I try to login, the page refreshes (I don’t see any exception on the consol). If I enter the user id/password for the second time, the login works perfectly
After extensive debugging this is what I found,
The first time when I try to login, the process action get called but it skips the managed bean and call the doView. The second time, the process action get called and the managed bean get called (login is successful) and then the doView get called. So I decided to take a look at the html output, sure enough the action url is different. The url for initil load is
action="/wps/portal/esb/!ut/p/c5/04_SB8K8xLLM9MSSzPy8xBz9CP0os3h355AAV0dnEwMLPycTA8_AUINQL1cLAwNXU_1wkA6zeAMcwNFA388jPzdVvyA7rxwAtTMgag!!/dl3/d3/L0lDU0lKSkpDZ3BSQ1FvS1VRa2chL29Gb2dBRUlRaGpGRUlBQWpPTTRSa0JTVkpRcEdnZ0d0QUEhIS80QzFiOVdfTnIwUkprQWxJTVJKa1FsTUlpUi1BLzdfR0NUUEVBQzQwOEdQRDBJUTFGUVQ2MzMwRzUvaWJtLmludi8xNDc3ODc5NDM0MDAvamF2YXguc2VydmxldC5pbmNsdWRlLnBhdGhfaW5mby8lMGpzcHMlMEVTQkxvZ2luUG9ydGxldFZpZXcuanNw/”
and the url after the first attempt to log in is,
action="/wps/portal/esb/!ut/p/c5/dVBHsoPIAjvLHIAy2bCEJhswqaFh4yKZYBNMhtPP-7u_GWmhhUpSlW7J7Y99ujVVujRDn35v6JawLxUEjiwAGudskcZ1F-LQkDkcl5lbdEM4_fJbbrTOBZkX2IL2cnErKCnLzP80PixbcorQg6IgXFALwr9M8r9W_D8g4DdbG7ryFt-S-_9tq470t00obsBSFK4yt-CGxtAzP6zOKQ6-zFgbhmonj9NYXMDQBZUQSxfpYzX7SkSCADgOujiRZCdG-60JFN3PGnR5ybH8ZXU5DtZ3H1rY88xwaBE5IwQ6x78oXEfRuiOKe9WXyAopGRCQT_jDM42lgrK_TGHPyk-g1J1S-d9w_CXXFcO_Nz49ZsTpSe_VZ45OkgeOdG8eFNi-pdxYCUTWZOMSJkG2DCBGqB1QdVeiqf5pqJEu9gleebgMHtuTNt37IR4IXqU4HbNYNN40KyO1W3lh7NR3sOewBJKX1KXWEFelg2lciJqklUX068fRNUzJuNUulevvXrnRbAaWZEhBWddE9qM1_gMrffrp9fjouTXpPMRTRGu-uMfxDn-9fE7ePjiTZ6ceGqnCfHVPzh7ucwV7sx8rwNEGm1JCVPQaa715RygFAiwcr72mgQ726FrWMWPchGbrp5Th3ZY9nDL5mEXIYSaA67MPaUAs9eiMlnFalHBRYnruS0asZU_YDo2Ugbl7KJplfRRitT0nMPCzqfICQExjlJjOPT4OPIRPo3EGYarhN50qHnihCJTZIFgURycbf8IiG5wSsvS4MYITZHUqYzDcNVC7cxvIen-_msergaAj6XtBo9GuWwADk8xSfb5jCslG0O8uem8wILCTobn3VGKkMHQ3xR9Xw5y9MoGHeKEaG0I5_JB2kmOW2eWTiJY4i9o6bLxzPwM5nwGSAif8fqCuffi36iX0Pu1OgcsF_95QIhOKKYUv9prKxO_6xbf3WmOSaJCDLfrRpPaK3CYnHFkt8oxodC8uG2fvJ2F4aLYyMd6vrb1IbL2fgESn2LPEf4ZSkH6PeaKONvL9mm5Prguu8ZvwMPzk7z6b1_OLI5iox6ivHBoZb32Y0far1f7atWl0jpaUYilQd9xIClj36LL3oTjZNbLmTiKaQcH8dcea7YFayk8bk3S2dC_8cn9afvJQ6ZAzOd-_cInXqhfj7eWb5Jj4nbXKK4k9mmJw6358T99Yvx1Rqpf6fj_FnJiKsQlPn7g7x1tjrwMTxvI3GbTALcHCI3fl-zw2rT_bYvONm7glRu93peJk7zG3sdtGzhb--RcqYJzK/dl3/d3/L0lDU0lKSkthWWtLQ2xFWm1ZQSEhL29Pb2dBRUlRaGpCS0VRQUFBRVpDZ0dRNEtRcGNFb2lBWUFEUkVBd0FCaUlCZ0FMRVFEQUFBQSEhLzRDMWI5V19OcnhRREVTWklKUkNBLzdfR0NUUEVBQzQwOEdQRDBJUTFGUVQ2MzMwRzUvMTQ3Nzg3OTY4NTYzL2phdmF4LnNlcnZsZXQuaW5jbHVkZS5wYXRoX2luZm8vJTBqc3BzJTBFU0JMb2dpblBvcnRsZXRWaWV3LmpzcA!!/"
Can some please explain me what going on here?
Thanks
i think i found a solution for my problem. it seems that JSF is trying to save it's viewstate in the session, but public session is not enabled by default for anonymous user. So changing the state saving method in web.xml from server to client seem to do the trick