Same log here, but in my case, I found the cause: I'm deploying a portlet web application "webapp-filename" on Liferay (on Glassfish).
The error occurs if "webapp-filename" and its context root "webapp-context-root" do not match. ICEfaces tries to connect to http://server-url/webapp-filename/block/message, but the web application is deployed on http://server-url/webapp-context-root.
Solution: (If using Glassfish)
- Edit the context-root in web-sun.xml to match your webapp filename.
I attach first related error log lines. Notice how logging the error enters a recursive endless loop. I always had to restart glassfish after this error.
[#|2010-01-10T16:21:44.632+0100|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-2;|16:21:44,631 INFO [AssociatedPageViews:44] using com.icesoft.faces.webapp.http.portlet.page.NoOpAssociatedPageViews
[#|2010-01-10T16:21:45.012+0100|SEVERE|sun-appserver2.1|com.icesoft.net.messaging.MessagePipeline|_ThreadID=22;_ThreadName=Timer-6;_RequestID=f8a03c2a-b3fc-4a03-a99b-2147784e4487;|
com.icesoft.net.messaging.MessageServiceException: java.io.FileNotFoundException: http://129.69.58.190:8080/llo-admin-filename/block/message
at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:292)
at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:151)
at com.icesoft.net.messaging.PublishTask.run(PublishTask.java:46)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.io.FileNotFoundException: http://129.69.58.190:8080/llo-admin-filename/block/message
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311)
at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:253)
... 4 more
[#|2010-01-10T16:21:45.031+0100|SEVERE|sun-appserver2.1|com.icesoft.net.messaging.MessagePipeline|_ThreadID=22;_ThreadName=Timer-6;_RequestID=f8a03c2a-b3fc-4a03-a99b-2147784e4487;|
com.icesoft.net.messaging.MessageServiceException: java.io.FileNotFoundException: http://129.69.58.190:8080/llo-admin-filename/block/message
at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:292)
at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:151)
at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
at com.icesoft.net.messaging.PublishTask.run(PublishTask.java:46)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.io.FileNotFoundException: http://129.69.58.190:8080/llo-admin-filename/block/message
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311)
at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:253)
... 5 more
[#|2010-01-10T16:21:45.036+0100|SEVERE|sun-appserver2.1|com.icesoft.net.messaging.MessagePipeline|_ThreadID=22;_ThreadName=Timer-6;_RequestID=f8a03c2a-b3fc-4a03-a99b-2147784e4487;|
com.icesoft.net.messaging.MessageServiceException: java.io.FileNotFoundException: http://129.69.58.190:8080/llo-admin-filename/block/message
at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:292)
at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:151)
at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
at com.icesoft.net.messaging.MessagePipeline.publish(MessagePipeline.java:159)
at com.icesoft.net.messaging.PublishTask.run(PublishTask.java:46)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.io.FileNotFoundException: http://129.69.58.190:8080/llo-admin-filename/block/message
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311)
at com.icesoft.net.messaging.http.HttpAdapter.publish(HttpAdapter.java:253)
... 6 more
I was able to reproduce this when doing a re-deploy of an ICEfaces application. When having an ICEfaces application deployed with the Push Server and the ICEfaces application gets exercised the Push Server is automatically detected by the Core. From this point on the communication is set up correctly. However, when a re-deploy is done, the newly deployed ICEfaces application hasn't detected the Push Server yet. If the user now browses away from the ICEfaces application the Bridge sends a final dispose-views request to the Push Server, which in turn sends it to the Core. As the communication hasn't been set up yet, the Core rejects the request. Making sure the Core sets up the communication with the Push Server upon receiving a message solves this issue. Marking this issue as FIXED.
Note that the Enterprise Push Server with its usage of JMS instead of HTTP as the means of communication does not suffer from this bug.