assuming you're clustering the JBoss instances and JBoss server supports WSRP (I haven't checked) it depends what your require in Session Management.
eg I just finished doing some fairly extensive WSRP
testing using Liferay and the support is very good, but while the Portlet spec defines management of state between portlets and portlet instances it does not define any inter-portlet state management. ie the how portlets would maintain and share session state. Portlets are supposed to communicate via IPC (JSR 286 not 168) and this is covered by WSRP, but again the concept of session-based state is not.
Stepping back to Liferay for a second, there are a few ways to share session state using Liferay-specific mechanisms and it is also possible to access the HTTP Session directly to manipulate state. Regardless of
how you maintain state and of whether you share state between portlets, the portal server tends to provide support for portlet state by delegating to the HTTP session and adding a prefix to the binding name to maintain a unique namespace and prevent collision. Because of this, portlet session clustering can be left to the general HTTP session clustering provided by the application server.
With a few provisos:
In Liferay (maybe others) a WSRP Consumer needs server affinity with a WSRP Producer for each conversation (is sticky connections). If you have multiple portlets, they need to be announced on the producer in a single WSRP Producer and they need to made available on the consumer using a single WSRP Consumer. If you do anything else, or have a mixture of remote and local portlets, you may find that session sharing fails.
That's more or less a direct brain dump of the WSRP session state testing we did with Liferay 6EE SP1
