You can easily reproduce the problem by running the chat-portlet example on Liferay. Only once instance is needed on a portal page. Bring up up the initial login panel and create a handle then click the button. This will start push and you can see in the client the tight request loop for getting the browser id.

Adding some logging shows odd behaviour when the BrowserDispatcher.service method is called. The first time through, no servlet has been registered yet:

BrowserDispatcher.service:
  browserId : 1gu01haq9
  dispatcher : org.icepush.servlet.MainServlet$1@12773a6
  servlets : {}

24-Oct-2011 7:08:05 PM org.icepush.servlet.EnvironmentAdaptingServlet <init>
INFO: Adapting to Thread Blocking environment

24-Oct-2011 7:08:05 PM org.icepush.servlet.BrowserDispatcher$BrowserEntry <init>
FINEST: New browser detected, assigning ID '1gu01haq9'.

But the next request that comes in has a different browser id in the cookie which doesn't match the one we originally stored:

BrowserDispatcher.service:
  browserId : 1gu5ua3fe
  dispatcher : org.icepush.servlet.MainServlet$1@12773a6
  servlets : {1gu01haq9=org.icepush.servlet.BrowserDispatcher$BrowserEntry@18476474}

24-Oct-2011 7:08:06 PM org.icepush.servlet.EnvironmentAdaptingServlet <init>
INFO: Adapting to Thread Blocking environment

24-Oct-2011 7:08:06 PM org.icepush.servlet.BrowserDispatcher$BrowserEntry <init>
FINEST: New browser detected, assigning ID '1gu5ua3fe'.

This cycle is just repeated where the new cookie value coming in does not match any of the values in the map of servlets.