Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Push Server
-
Labels:None
-
Environment:ICEFaces3 EE + push + WebSphere Portal 7 + MyFaces 2.1.6
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration
Description
The ICEPush QueueConsumer task in LocalPushGroupManager fetches a Notification object (implements Runnable) off the queue, and calls run(); On WebSphere, this is throwing the following exception:
java.lang.RuntimeException: java.lang.IllegalStateException: prepareThread not called for Thread Thread[Notification queue consumer.,5,main]
Which causes the queue consumer timer to exit. This is responsible for <noop/> responses to the blocking connections not showing up.
There are other exceptions as well. The FixedXMLContentHandler also throws a similar exception when trying to modify the response headers. It throws a very similar exception. I'll add more stack traces to this JIRA as I find them
java.lang.RuntimeException: java.lang.IllegalStateException: prepareThread not called for Thread Thread[Notification queue consumer.,5,main]
Which causes the queue consumer timer to exit. This is responsible for <noop/> responses to the blocking connections not showing up.
There are other exceptions as well. The FixedXMLContentHandler also throws a similar exception when trying to modify the response headers. It throws a very similar exception. I'll add more stack traces to this JIRA as I find them
Issue Links
- blocks
-
IPCK-259
Add ICEfaces EE Support for WebSphere Portal 7
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Our standard thread-blocking technique for doing Ajax Push does not work with WebSphere Portal due to use of a thread local variable to provide the current portal context. This context is therefore not available in the TimerTasks that we run when doing our basic Ajax Push. It would be difficult to fix and maintain a strategy to ensure that the portlet context and other associated information in the thread local were available to these other threads.
EPS however used a different strategy and testing shows that it works with our portlet examples that use Ajax Push (e.g. Progress Bar Ajax). So it's been decided that, for Ajax Push in WebSphere Portal, that EPS will be a required part of the distribution.