voyent
IceFaces EE - Redirect causes Network Connection Interrupted  XML
Forum Index -> Portals & Portlets
Author Message
palmerwill

Joined: 17/Oct/2011 04:07:06
Messages: 6
Offline


We're currently in the process of migrating from Liferay 5.2.3/IceFaces 1.8.2 -> Liferay 6.x/IceFaces 3 EE.

I'm receiving a dialog box popup (all be it briefly) stating: 'Network Connection Interrupted To reconnect click the Reload button on the browser or click the button below' when I perform an automatic redirection.

The use case is such:
1. User action in portlet A causes a new thread to be spawned which sends a message elsewhere (B) for processing (ROOT webapp component)
2. B performs some processing and then conditionally decides to send a message back to A
3. A receives the message and performs a redirect

Previously within IceFaces 1.8.2, we were able to use the PersistentFacesState to perform the redirect. With the introduction of IceFaces 3 EE this is no longer an option.

What is the best method of facilitating such a use case with IceFaces 3 embedded within Liferay?

I am no expert with this, so please excuse/mention any obvious blunders....
I've already tried the following:

When the 'message' is received from B, request a re-render using the PortableRenderer
A. a filter configured within ROOT web.xml, didn't work
B. a redirecting phase listener with code in the afterPhase (RESTORE_VIEW) to perform the redirect. This works, but I get the 'Network Connection Interrupted' error for approximately a second/half before the browser redirects.
dsinotte

Joined: 14/Nov/2006 00:00:00
Messages: 33
Offline


This looks fairly complex. If I had to guess, I'd say the "Network" popup is occurring because the original request that started the whole thing has not actually returned before another process/thread ends up triggering the redirect. ICEfaces likely detects this as a "severed" connection and puts up the warning.

A quick thing to try would be to set this context parameter:

http://www.icesoft.org/wiki/display/ICE/disableDefaultErrorPopups

It's definitely not a fix but would likely prevent the popup for the time being.

It would be better to try and get the original request thread to return the redirect. The API for that is on the ExternalContext:

Code:
        FacesContext.getCurrentInstance().getExternalContext().redirect(yourURL);
 


That call must be done from the request thread though as the FacesContext is a thread local and is only available on that thread.
palmerwill

Joined: 17/Oct/2011 04:07:06
Messages: 6
Offline


Thanks Deryk,
I'll try the error disabling tomorrow morning.

Any idea how to get hold of the request thread in some fashion?

Also, would the icecore:redirect tag of Ice 3.1 be of use perhaps?
dsinotte

Joined: 14/Nov/2006 00:00:00
Messages: 33
Offline


Without knowing more about how your code, it's tough to comment on how the initial request thread is behaving. Is it blocked in some way when you spawn off your own new thread?

I'd forgotten about the ice:core href setting but that's definitely worth a try as well using the PortableRender approach.
palmerwill

Joined: 17/Oct/2011 04:07:06
Messages: 6
Offline


I tried the icecore:redirect function, what version of 3 EE is it available in?
The version we're trialing doesn't appear to support it, although it is a number of months old now as we've been delayed.

With regards to how my code is working (using the phase listener redirection approach). I'm doing the following:
1. Portlet (A) upon user performing some action fires a message
2. Object (B) receives the message and conditionally determines if to send a message back
3. (A) receives a message (sometimes), sets a value in session object (C)
4. (A) requests a re-render using a PortableRenderer
5. Re-rendering causes the phase listener to be called (which pulls a value from the session object (C) that conditions the request of a redirect from the phase listener. We're not spawning any new threads at this point.

Q: Would (5) likely be on the request thread as it's part of the JSF render cycle.


Of course, an updated 3-EE version with icecore:redirect support if it works as expected would make my approach defunct anyway.
palmerwill

Joined: 17/Oct/2011 04:07:06
Messages: 6
Offline


FYI,
Disabling the error messages causes my usage of the phase listener to look like it's functioning perfectly, i.e. no network connection interrupted popup.
dsinotte

Joined: 14/Nov/2006 00:00:00
Messages: 33
Offline


The redirect feature of icecore was added as of 3.1:

http://www.icesoft.org/wiki/display/ICE/redirect

so it won't be available in ICEfaces 3.0 EE. It will be available in 3.2 EE but I don't have a timeline for that release yet. Likely in the next month or so.

Following the steps you've posted:

1) The client performs an action. This starts a request thread with a valid FacesContext. It fires a message. What kind of message is this? If it doesn't create a new thread then this message is sent on the current request thread.

2) Object B receives the message. What is Object B? Is it an instance of something in Portlet A? Is it part of a different portlet and is that portlet in the same .war file or different .war file as Portlet A? Again, if a new thread has not been used, this is still on the original request thread.

3) If conditions are met, Portlet A receives a message back. Again, if there are no new threads, this is still the request thread. It sets something in the session. Does it set in portlet scope or application scope?

4) Using Ajax Push at this point will trigger the server to send the client (browser) a response telling it to issue a new request. If the thread *is* the original request thread, then you might be able to use the ExternalContext.redirect() API rather than do an Ajax Push.

5) The new request triggers the JSF lifecycle and invokes your phase listener logic.
palmerwill

Joined: 17/Oct/2011 04:07:06
Messages: 6
Offline


dsinotte wrote:

1) The client performs an action. This starts a request thread with a valid FacesContext. It fires a message. What kind of message is this? If it doesn't create a new thread then this message is sent on the current request thread.
 


The message fired is a concrete implementation of an interface. It contains some payload, upon which other decisions can be made. It's fired via an event manager. The sender is de-coupled from the destination and knows nothing about it. It's fired using a thread pool for performance as there are likely multiple 'listeners' to said event.

dsinotte wrote:

2) Object B receives the message. What is Object B? Is it an instance of something in Portlet A? Is it part of a different portlet and is that portlet in the same .war file or different .war file as Portlet A? Again, if a new thread has not been used, this is still on the original request thread.
 


Object B is a custom controller in the ROOT web app. By this point, it's running in one of the threads in the thread pool. The message sent back (depending upon conditions) is sent back using the same thread pool (perhaps different thread or the same thread)

dsinotte wrote:

3) If conditions are met, Portlet A receives a message back. Again, if there are no new threads, this is still the request thread. It sets something in the session. Does it set in portlet scope or application scope?
 


The thread is one from the thread pool.
The session value is set in the portlet scope. The portlet where the session value is set is the same portlet that requests the re-render via a PortableRenderer and so the value exists for the given portlet session when the phase listener is called


dsinotte wrote:

4) Using Ajax Push at this point will trigger the server to send the client (browser) a response telling it to issue a new request. If the thread *is* the original request thread, then you might be able to use the ExternalContext.redirect() API rather than do an Ajax Push.
 


Not the original request thread, but I understand where you're coming from.

dsinotte wrote:

5) The new request triggers the JSF lifecycle and invokes your phase listener logic.
 
 
Forum Index -> Portals & Portlets
Go to:   
Powered by JForum 2.1.7ice © JForum Team