Forums de discussion
Liferay 6.1 and Icefaces 1.82 push server issue
William Gosse, modifié il y a 11 années.
Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Master Publications: 533 Date d'inscription: 04/07/10 Publications récentes
I'm having an issue with deploying Icefaces 1.82 push server on to Liferay 6.1.
Even though the push-server.war is getting deployed ok in the webapp directory Icefaces says it can't find it.
This combo worked fine in 6.05.
Even though the push-server.war is getting deployed ok in the webapp directory Icefaces says it can't find it.
This combo worked fine in 6.05.
Neil Griffin, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Legend Publications: 2655 Date d'inscription: 27/07/05 Publications récentes
Probably best for you to open an issue with ICEsoft. The only (currently open) issue that I'm aware of regarding the Enterprise Push Server is FACES-1171.
William Gosse, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Master Publications: 533 Date d'inscription: 04/07/10 Publications récentes
Hi Neil,
How are you and congrads on your new job.
Deploying the push server or not is kind of side show to a bigger issue I have. I added some new portlets to a new portal I've been developing started getting the following exceptions below. Eventually Icefaces just stops responding to requests. I've been pulling my hair out trying to find an answer to this problem and thought the push server would help. I've never seen this exception before and hop you might have some insights:
2012-06-25 14:05:11,523 ERROR PersistentFacesState:181 - Exception occured during execute push on /jspx/battlecards/battlecardsDisplay.jspx
javax.faces.FacesException: javax.faces.model.NoRowAvailableException
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:128)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:175)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:311)
at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:141)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.faces.model.NoRowAvailableException
at javax.faces.model.ListDataModel.getRowData(ListDataModel.java:150)
at com.icesoft.faces.component.panelseries.UISeries.getRowData(UISeries.java:130)
at com.icesoft.faces.component.panelseries.UISeries.loadRowToRequestMap(UISeries.java:181)
at com.icesoft.faces.component.panelseries.UISeries.processCurrentRowData(UISeries.java:172)
at com.icesoft.faces.component.panelseries.UISeries.setRowIndex(UISeries.java:146)
at com.icesoft.faces.component.ext.renderkit.TableRenderer.encodeChildren(TableRenderer.java:912)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:840)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:357)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:95)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:840)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:493)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:498)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:498)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:498)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:468)
at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:158)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
... 7 more
How are you and congrads on your new job.
Deploying the push server or not is kind of side show to a bigger issue I have. I added some new portlets to a new portal I've been developing started getting the following exceptions below. Eventually Icefaces just stops responding to requests. I've been pulling my hair out trying to find an answer to this problem and thought the push server would help. I've never seen this exception before and hop you might have some insights:
2012-06-25 14:05:11,523 ERROR PersistentFacesState:181 - Exception occured during execute push on /jspx/battlecards/battlecardsDisplay.jspx
javax.faces.FacesException: javax.faces.model.NoRowAvailableException
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:128)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:175)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:311)
at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:141)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.faces.model.NoRowAvailableException
at javax.faces.model.ListDataModel.getRowData(ListDataModel.java:150)
at com.icesoft.faces.component.panelseries.UISeries.getRowData(UISeries.java:130)
at com.icesoft.faces.component.panelseries.UISeries.loadRowToRequestMap(UISeries.java:181)
at com.icesoft.faces.component.panelseries.UISeries.processCurrentRowData(UISeries.java:172)
at com.icesoft.faces.component.panelseries.UISeries.setRowIndex(UISeries.java:146)
at com.icesoft.faces.component.ext.renderkit.TableRenderer.encodeChildren(TableRenderer.java:912)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:840)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:357)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:95)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:840)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:493)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:498)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:498)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:498)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:468)
at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:158)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
... 7 more
Neil Griffin, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Legend Publications: 2655 Date d'inscription: 27/07/05 Publications récentes
Any chance you can upgrade to ICEfaces 3 and Liferay Faces Bridge? ICEfaces 1.8 sends all Ajax requests directly to the PersistenFacesServlet, which bypasses the portlet lifecycle. One big benefit of upgrading is that all Ajax requests go through the portlet container as ResourceRequests.
Please paste some/all of the markup from battlecardsDisplay.jspx, especially the ice:panelSeries part.
Please paste some/all of the markup from battlecardsDisplay.jspx, especially the ice:panelSeries part.
William Gosse, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Master Publications: 533 Date d'inscription: 04/07/10 Publications récentes
Hi Neil,
I've attached both the jspx and the backing bean. It's kind of a big portlet.
Thanks,
Not sure how difficult it would be to upgrade to 3.0. Tried going to 2.0 in the past but it broke some of my code. I have lots of other 1.82 portlet that seem to work fine on both this new portal and my old portal that's kind of why I stuck with 1.82.
One hypothesis I have is that the session is timeout while a popup is open.
I also start to see several "WARN ReceivePing:75 - could not get a valid queue for 26". Not sure if this is significant.
Also I'm not using any ice:panelSeries tags, but I am using datatables
I've attached both the jspx and the backing bean. It's kind of a big portlet.
Thanks,
Not sure how difficult it would be to upgrade to 3.0. Tried going to 2.0 in the past but it broke some of my code. I have lots of other 1.82 portlet that seem to work fine on both this new portal and my old portal that's kind of why I stuck with 1.82.
One hypothesis I have is that the session is timeout while a popup is open.
I also start to see several "WARN ReceivePing:75 - could not get a valid queue for 26". Not sure if this is significant.
Also I'm not using any ice:panelSeries tags, but I am using datatables
Pièces jointes:
Neil Griffin, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Legend Publications: 2655 Date d'inscription: 27/07/05 Publications récentes
I think there could be two problems in the following method:
1) Performance: Since managed-bean getter methods can be called many many times during the execution of the JSF lifecycle, the recommended practice is to always use lazy-initialization. For example:
I would also recommend that you put in a System.err.println at the top of the method to see how often it gets called. I bet it's called a lot.
2) The call to SessionRenderer.render(groupName) should not be in a getter-method like this. Instead, it should be called when a button is clicked by the user, or when an asynchronous event happens on the server. Also because of problem#1, the call to SessionRenderer.render(groupName) is probably happening a bunch of times.
public List<battlecardentry> getBattlecards() {
battlecards = (List<battlecardentry>) ApplicationAttribute
.getApplicationAttribute(CURRENT_BATTLECARDS_KEY);
// we only want to sortColumnName if the column or ordering has changed.
if (!oldSort.equals(sortColumnName) || oldAscending != ascending) {
sort();
oldSort = sortColumnName;
oldAscending = ascending;
}
SessionRenderer.render(groupName);
return battlecards;
}
</battlecardentry></battlecardentry>
1) Performance: Since managed-bean getter methods can be called many many times during the execution of the JSF lifecycle, the recommended practice is to always use lazy-initialization. For example:
public List<battlecardentry> getBattlecards() {
if (battlecards == null) {
battlecards = (List<battlecardentry>) ApplicationAttribute
.getApplicationAttribute(CURRENT_BATTLECARDS_KEY);
// we only want to sortColumnName if the column or ordering has changed.
if (!oldSort.equals(sortColumnName) || oldAscending != ascending) {
sort();
oldSort = sortColumnName;
oldAscending = ascending;
}
SessionRenderer.render(groupName);
}
return battlecards;
}
</battlecardentry></battlecardentry>
I would also recommend that you put in a System.err.println at the top of the method to see how often it gets called. I bet it's called a lot.
2) The call to SessionRenderer.render(groupName) should not be in a getter-method like this. Instead, it should be called when a button is clicked by the user, or when an asynchronous event happens on the server. Also because of problem#1, the call to SessionRenderer.render(groupName) is probably happening a bunch of times.
William Gosse, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Master Publications: 533 Date d'inscription: 04/07/10 Publications récentes
Oh boy, I can't believe I put the SessionRenderer.render(groupName) call in a getter. I've used this hundreds of times before but never inside a getter. I just went back and double checked my usage of SessionRenderer.render(groupName) in my other code. In no other case was it in a getter. I must of had a momentary lapse of sanity.
I'm hoping that this might be the cause of my original problem only because I've never experienced this issue before with any of my previous code.
In any event its a necessary fix.
Thanks Neil for catching this one for me.
I'm hoping that this might be the cause of my original problem only because I've never experienced this issue before with any of my previous code.
In any event its a necessary fix.
Thanks Neil for catching this one for me.
Neil Griffin, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Legend Publications: 2655 Date d'inscription: 27/07/05 Publications récentes
My pleasure Bill -- hope everything works out fine.
William Gosse, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Master Publications: 533 Date d'inscription: 04/07/10 Publications récentes
Removing that render for the getter did clear up my NoRowFound exception.
But I'm still seeing "WARN ReceivePing:75 - could not get a valid queue for" in my log.
Can you tell me what that's about?
But I'm still seeing "WARN ReceivePing:75 - could not get a valid queue for" in my log.
Can you tell me what that's about?
Neil Griffin, modifié il y a 11 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Legend Publications: 2655 Date d'inscription: 27/07/05 Publications récentes
Hi Bill,
I haven't seen that one before. You might want to search the ICEsoft Issue Tracker or the ICEsoft forums to see if anyone has run into that.
Neil
I haven't seen that one before. You might want to search the ICEsoft Issue Tracker or the ICEsoft forums to see if anyone has run into that.
Neil
Neil Francese, modifié il y a 9 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
New Member Publications: 22 Date d'inscription: 03/04/12 Publications récentes
Ever find out what this error was from?
William Gosse, modifié il y a 9 années.
RE: Liferay 6.1 and Icefaces 1.82 push server issue
Liferay Master Publications: 533 Date d'inscription: 04/07/10 Publications récentes
Sorry but this was a while back so I don't remember if it ever got resolved. I've moved onto Primefaces since then.