Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8
-
Component/s: None
-
Labels:None
-
Environment:Environment:
1) Liferay v5.2.2 with bundled Tomcat 6.0.18
2) JDK v1.6.0_07
3) Icefaces v1.8.0
4) JBoss Seam v2.1.1.GA
-
ICEsoft Forum Reference:
Description
1) There are two different portlets from separate WAR archives deployed on the server. No IPC between portlets.
2) Portlets are fully functional, when added to public page (no authenticated user).
3) Portlets still remain fully functional after public page refresh (F5) (no authenticated user).
4) Portlets are fully functional, when added to public page and viewed with user authenticated.
5) Portlets are not functional after page refresh (F5), when viewed with user authenticated.
- None of the components are responsive (tabs of tabbed pane do not change, button actionListeners are not invoked - tried with debuger at the start of actionListener method - call does not come, etc.)
- Noticed that rvn=<some_number> parameter appears in the URL. And it seems to me that page reload is executed on every user action with the UI and this is not what is expected from AJAX driven technology such as ICEFaces.
For the simple test case:
The same behaviour is noticed in location sample provided with ICEfaces source distribution when building with default target for liferay on tomcat 6: I mean that after logged in user refreshes (F5) the page, details portlet does not update after selecting location from find portlet.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Deryk Sinotte [ deryk.sinotte ] |
Is there any news for this issue?
We are working on complex risk assessment management system framework and ICEFaces together with Liferay portlet container were chosen for web UI implementation of some boundary components.
It will cost too much time for rethinking system architecture from the point of view of chosen technolgies, tools or frameworks. Keep in mind, that this kind of technological errors is hardly predictable, so we got a surprise in the middle of our path. And of course, we have chosen to do most components in purely opensource way, so paying for support is not an option for us.
Thank you very much.
I have been looking at the issue while working on other things but I haven't been able to track down the problem yet. I'll continue to look at it as time and priorities permit.
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #19076 | Thu Jul 16 10:16:11 MDT 2009 | deryk.sinotte | |
| Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/async/render/GroupAsyncRenderer.java
|
Turns out this was a pretty subtle bug - hard to categorize and track down. The issue was related to couple of different things:
- The mechansim that the SessionRenderer API uses for tracking sessions and allowing for cleanup.
- The unpredictable nature of session handling in the container.
In a nutshell, the SessionRenderer API and corresponding render groups are storing Servlet/PortletSession instances via WeakReferences. That way, when the session goes away, the cleanup is done in a reliable and relatively safe manner. Unfortunately, the servlet/portal container can handle the creation and destruction of session instances however it sees fit. So even though the session id might be the same, the underlying session object does not have to be. And this appears to have been the problem. Session instances were being destroyed/recycled by the container so that, even though we had the same session id, the underlying session instance was completely different on each reload. There's a bit of mystery about why it would work as often as it did as the sessions were generally available to be removed a lot more frequently than they were but all of that is done under the hood in the container.
Since it's generally not a good idea to try and keep references to the session objects themselves (their management is not specified so the container is allowed to do what they will with them), I've modified the group renderers to not handle the sessions directly. I've changed the GroupAsyncRenderer to use the session id rather than the actual session. This requires that we do small bit of work on the cleanup side when a session is no longer valid, but it also means that push now continues to work when reloading the page with portlets on it.
Checked in change to GroupAsyncRenderer so that SessionRenderer API uses the session ids rather than the actual session references.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Fix Version/s | 1.8.2 [ 10190 ] | |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 1.8.2-RC1 [ 10210 ] |
I am experiencing this exact same behaviour using Webspace 10.1
We are using icefaces 1.8.2
jdk 1.6.0_16
We are not using Seam
I have enabled push-server to see if that would help, but it has not. Any idea of what I should check?
| Status | Resolved [ 5 ] | Closed [ 6 ] |
I'm having the same issue as Brad with the same setup: Webspace 10.1 + ICEfaces 1.8.2
Can anybody please help?
I've doing some testing trying to confirm this and narrow it down.
When testing with 1.8.0 with the Location portlets on Liferay 5.2.2, I could see the described behaviour in both Firefox and IE7. Reloading the page as an authenticated user seemed to cause the portlets to stop working.
I then tested with ICEfaces 1.8.1, and that seemed to work well with Firefox - I could reload as a guest or as an authenticated user - and the portlets continued to function. With IE, it seems that reloading either as an authenticated user or as a guest leads to the portlets not responding. Not sure of the details as to why this is yet. First glance appears that perhaps the DOM update is affected in some way but I'm unsure why this would only affect IE.