Assigning to Mircea.

Also meant to add that I'm seeing, on the client, two values for the browser cookie. From Chrome's console:

Cookie:csfcfc=3Xfn_3Xfn; ice.push.browser=8agu5rj1qg; COOKIE_SUPPORT=true; ice.push.browser=1gu01haq9; COMPANY_ID=1; ID=3670776a4d466c2b7356493d; PASSWORD=50514d304c3651686973303d; LOGIN=6272756e6f4037636f67732e636f6d; SCREEN_NAME=50514d304c3651686973303d; LFR_SESSION_STATE_10870=1319240774163; ice.pushids=; JSESSIONID=9B4C6C91F276F2815EBD4477692C2B16; GUEST_LANGUAGE_ID=en_US; ice.connection.contextpath=/; ice.connection.running=ba44d:acquired; ice.connection.lease=1319479979999

Perhaps the cookie pathing logic is not quite working in portlets.

This issue prevents Ajax Push from operating properly with portlets when running with MyFaces.

So it looks as if the problem is related to ConfigurationServer and some logic about redirect. Logging indicates that when the request comes in with a cookie that has an unknown browser id, we set a new one and add it as a BrowserEntry but right after that, we send a response back with a newly generated one. Because of this, the next browser id cookie is always "new".

BrowserDispatcher.service:
browserId : 1guh72fju
dispatcher : org.icepush.servlet.MainServlet$1@3abc6623
servlets :

BrowserDispatcher.checkSession: could not find 1guh72fju
1-Nov-2011 5:51:31 PM org.icepush.servlet.EnvironmentAdaptingServlet <init>
INFO: Adapting to Thread Blocking environment
1-Nov-2011 5:51:31 PM org.icepush.servlet.BrowserDispatcher$BrowserEntry <init>
FINEST: new browser detected with id 1guh72fju
1-Nov-2011 5:51:31 PM org.icepush.ConfigurationServer$SetBrowserID writeTo
FINE: new browser id generated: 2guh72fkh

BrowserDispatcher.getBrowserIDFromCookie:
name : ice.push.browser
value : 2guh72fkh
path : null
BrowserDispatcher.service:
browserId : 2guh72fkh
dispatcher : org.icepush.servlet.MainServlet$1@3abc6623
servlets :

BrowserDispatcher.checkSession: could not find 2guh72fkh
1-Nov-2011 5:51:31 PM org.icepush.servlet.EnvironmentAdaptingServlet <init>
INFO: Adapting to Thread Blocking environment
1-Nov-2011 5:51:31 PM org.icepush.servlet.BrowserDispatcher$BrowserEntry <init>
FINEST: new browser detected with id 2guh72fkh
1-Nov-2011 5:51:31 PM org.icepush.ConfigurationServer$SetBrowserID writeTo
FINE: new browser id generated: 3guh72fl7

The problem appears to be in ConfigurationServer.service. In here there is a check based on "redirect || request.containsParameter("ice.sendConfiguration")" which is always true because redirect is always true. Once inside the block, the browserIDCookie is always "null" so we immediately send back a response with a newly generated browser id and the cycle repeats:

public void service(Request request) throws Exception {
Cookie browserIDCookie = Cookie.readCookie(request, BrowserIDCookieName);

if (redirect || request.containsParameter("ice.sendConfiguration")) {
boolean browserIDNotSet = browserIDCookie == null;
if (nonDefaultConfiguration && browserIDNotSet)

else if (nonDefaultConfiguration)

else if (browserIDNotSet)

else

} else

}

So either the redirect calculation is incorrect or the check for the cookie is not being done properly. Logging that particular section shows that the redirect calculation will always be true

redirect = context != null && !servletContext.getContextPath().equals(contextPath);

because the two context paths never match.

ConfigurationServer:
context : org.icepush.PushContext@2c26618f
original context path: null
servlet context path : /chat-portlet
match : false

At this point, I'm not sure if the non-matching context paths are the root issue or whether the null "Cookie" header value check afterward is the ultimate culprit.

Mircea suggested fixing the logic where we attempt to find the Cookie header. It appears that Liferay (or perhaps the PortletFaces Bridge) may be stripping out the actual "Cookie" header but it's still available via the original request.getCookies() method. So I've added an extra attempt to get the cookie via this method.