Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.0.BETA
-
Fix Version/s: 4.0
-
Component/s: Push Library
-
Labels:None
-
Environment:Portlet
-
Assignee Priority:P1
Description
Push doesn't seem to be working properly in portlets. When I initially load up the chat portlet, I'll get the following exception almost right away:
Exception in thread "Timer-2" java.lang.NullPointerException
at com.liferay.faces.bridge.container.PortletContainerImpl.getRequestParameter(PortletContainerImpl.java:528)
at com.liferay.faces.bridge.context.map.RequestParameterMapImpl.getProperty(RequestParameterMapImpl.java:107)
at com.liferay.faces.bridge.context.map.RequestParameterMapImpl.getProperty(RequestParameterMapImpl.java:37)
at com.liferay.faces.util.map.AbstractPropertyMap.get(AbstractPropertyMap.java:106)
at org.icefaces.impl.push.servlet.ProxyHttpServletRequest.getParameter(ProxyHttpServletRequest.java:169)
at org.icepush.servlet.ServletRequest.checkExistenceOf(ServletRequest.java:260)
at org.icepush.servlet.ServletRequest.getParameter(ServletRequest.java:150)
at org.icepush.servlet.ServletRequest.getParameterAsLong(ServletRequest.java:189)
at org.icepush.servlet.ServletPushRequest.getHeartbeatInterval(ServletPushRequest.java:53)
at org.icepush.servlet.ServletPushRequestResponse.getHeartbeatInterval(ServletPushRequestResponse.java:62)
at org.icepush.http.standard.PushRequestProxy.getHeartbeatInterval(PushRequestProxy.java:45)
at org.icepush.BlockingConnectionServer.resetTimeout(BlockingConnectionServer.java:247)
at org.icepush.BlockingConnectionServer.sendNotifications(BlockingConnectionServer.java:179)
at org.icepush.BlockingConnectionServer.receive(BlockingConnectionServer.java:292)
at org.icepush.LocalNotificationBroadcaster$BroadcastTask.run(LocalNotificationBroadcaster.java:77)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
After that, chat is operational but the updates only occur during heartbeats, not when a message is sent. The exception only occurs the first time the page is rendered. If I switch to a different portlet page (like the Welcome page with no ICEfaces portlets) and then switch back, I don't see the exception but push still has the same behaviour where updates only occur during heartbeats.
I logged the various parameters that were being requested to see if there was something obvious. Perhaps the view and/or simulator parameters are important clues:
ProxyHttpServletRequest.getParameter: view : null
ProxyHttpServletRequest.getParameter: simulator : null
ProxyHttpServletRequest.getParameter: view : null
ProxyHttpServletRequest.getParameter: simulator : null
ProxyHttpServletRequest.getParameter: ice.push.browser : 2fuhtai5tun
ProxyHttpServletRequest.getParameter: ice.push.browser : 2fuhtai5tun
ProxyHttpServletRequest.getParameter: ice.sendConfiguration : null
ProxyHttpServletRequest.getParameter: ice.pushid : v24ua682
ProxyHttpServletRequest.getParameter: ice.push.heartbeat : 15000
ProxyHttpServletRequest.getParameter: ice.push.heartbeat : 15000
ProxyHttpServletRequest.getParameter: ice.pushid : v24ua682
I've also seen this occasionally but it's not consistent and is could be app related or related to the issue above.
Caused by: java.lang.RuntimeException: FacesContext is not present for thread Thread[http-bio-8080-exec-20,5,main]
at org.icefaces.application.PushRenderer.missingFacesContext(PushRenderer.java:284)
at org.icefaces.application.PushRenderer.render(PushRenderer.java:193)
at org.icefaces.sample.portlet.chat.ChatRoom.addMessage(ChatRoom.java:90)
at org.icefaces.sample.portlet.chat.ChatRoom.removeParticipant(ChatRoom.java:64)
at org.icefaces.sample.portlet.chat.Participant.logout(Participant.java:130)
Exception in thread "Timer-2" java.lang.NullPointerException
at com.liferay.faces.bridge.container.PortletContainerImpl.getRequestParameter(PortletContainerImpl.java:528)
at com.liferay.faces.bridge.context.map.RequestParameterMapImpl.getProperty(RequestParameterMapImpl.java:107)
at com.liferay.faces.bridge.context.map.RequestParameterMapImpl.getProperty(RequestParameterMapImpl.java:37)
at com.liferay.faces.util.map.AbstractPropertyMap.get(AbstractPropertyMap.java:106)
at org.icefaces.impl.push.servlet.ProxyHttpServletRequest.getParameter(ProxyHttpServletRequest.java:169)
at org.icepush.servlet.ServletRequest.checkExistenceOf(ServletRequest.java:260)
at org.icepush.servlet.ServletRequest.getParameter(ServletRequest.java:150)
at org.icepush.servlet.ServletRequest.getParameterAsLong(ServletRequest.java:189)
at org.icepush.servlet.ServletPushRequest.getHeartbeatInterval(ServletPushRequest.java:53)
at org.icepush.servlet.ServletPushRequestResponse.getHeartbeatInterval(ServletPushRequestResponse.java:62)
at org.icepush.http.standard.PushRequestProxy.getHeartbeatInterval(PushRequestProxy.java:45)
at org.icepush.BlockingConnectionServer.resetTimeout(BlockingConnectionServer.java:247)
at org.icepush.BlockingConnectionServer.sendNotifications(BlockingConnectionServer.java:179)
at org.icepush.BlockingConnectionServer.receive(BlockingConnectionServer.java:292)
at org.icepush.LocalNotificationBroadcaster$BroadcastTask.run(LocalNotificationBroadcaster.java:77)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
After that, chat is operational but the updates only occur during heartbeats, not when a message is sent. The exception only occurs the first time the page is rendered. If I switch to a different portlet page (like the Welcome page with no ICEfaces portlets) and then switch back, I don't see the exception but push still has the same behaviour where updates only occur during heartbeats.
I logged the various parameters that were being requested to see if there was something obvious. Perhaps the view and/or simulator parameters are important clues:
ProxyHttpServletRequest.getParameter: view : null
ProxyHttpServletRequest.getParameter: simulator : null
ProxyHttpServletRequest.getParameter: view : null
ProxyHttpServletRequest.getParameter: simulator : null
ProxyHttpServletRequest.getParameter: ice.push.browser : 2fuhtai5tun
ProxyHttpServletRequest.getParameter: ice.push.browser : 2fuhtai5tun
ProxyHttpServletRequest.getParameter: ice.sendConfiguration : null
ProxyHttpServletRequest.getParameter: ice.pushid : v24ua682
ProxyHttpServletRequest.getParameter: ice.push.heartbeat : 15000
ProxyHttpServletRequest.getParameter: ice.push.heartbeat : 15000
ProxyHttpServletRequest.getParameter: ice.pushid : v24ua682
I've also seen this occasionally but it's not consistent and is could be app related or related to the issue above.
Caused by: java.lang.RuntimeException: FacesContext is not present for thread Thread[http-bio-8080-exec-20,5,main]
at org.icefaces.application.PushRenderer.missingFacesContext(PushRenderer.java:284)
at org.icefaces.application.PushRenderer.render(PushRenderer.java:193)
at org.icefaces.sample.portlet.chat.ChatRoom.addMessage(ChatRoom.java:90)
at org.icefaces.sample.portlet.chat.ChatRoom.removeParticipant(ChatRoom.java:64)
at org.icefaces.sample.portlet.chat.Participant.logout(Participant.java:130)
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
We have encountered a similar issue like this before: PUSH-239
Show
Jack Van Ooststroom
added a comment - We have encountered a similar issue like this before: PUSH-239
Upon receiving the incoming listen.icepush request the resetTimeout(...) method is invoked in the BlockingConnectionServer. This method queries the request. If no update is available the request is added to the queue. When a push request comes in and interested BlockingConnectionServers have been found, the resetTimeout(...) method again is invoked, but this time from a spawned thread. This behavior does not work in a Portal environment. I added a "caching" mechanism to the ServletPushRequest class caching any previously retrieved info specific to a PushRequest. Upon invoking the resetTimeout(...) from a spawned thread, this information is now retrieved from the various "cached" values. Marking this one as FIXED.
Show
Jack Van Ooststroom
added a comment - Upon receiving the incoming listen.icepush request the resetTimeout(...) method is invoked in the BlockingConnectionServer. This method queries the request. If no update is available the request is added to the queue. When a push request comes in and interested BlockingConnectionServers have been found, the resetTimeout(...) method again is invoked, but this time from a spawned thread. This behavior does not work in a Portal environment. I added a "caching" mechanism to the ServletPushRequest class caching any previously retrieved info specific to a PushRequest. Upon invoking the resetTimeout(...) from a spawned thread, this information is now retrieved from the various "cached" values. Marking this one as FIXED.
Sending icepush/core/src/main/java/org/icepush/LocalNotificationBroadcaster.java
Sending icepush/core/src/main/java/org/icepush/servlet/ServletPushRequest.java
Transmitting file data ..
Committed revision 40507.