Portlet Session nightmare

[vmaurik3]

We have been in the process of moving to portlets over the past few months. We were using Liferay bundled with Tomcat for development, but we are required to use OAS in production by our customer. So one of the DBAs set up Liferay to use Oracle as its database and to run on OAS.

Our application works fine on the Tomcat version, but as soon as we deploy it to OAS it stops working. The page displays, but as soon as you click a link, the page flashes and comes back to its original state... or so it seems.

When we actually started looking into the logging, we found that for some reason, each request is getting a new Session. This means the Form object which Spring puts on the Session is not found, and it thus creates yet another new Session. At this point it is basically as if you were coming to the page the first time, as the _targetx has long been lost.

If anyone could suggest where I should begin to look, I would greatly appreciate it. If you need more information, I can post that as requested.

[Jörg Heinicke]

That's nearly for sure a matter of the container, so OAS vs. Tomcat. Since I don't know OAS at all I can't really help. Is it only your portlets that don't work or the whole portal? You use Spring portlet MVC? Are the portlets deployed in a different webapp than the portal (but actually this shouldn't matter)?

Jörg

[vmaurik3]

Liferay appears to be working correctly. The DBA who sset this up deployed a calculator portlet that he got from somewhere and it seems to work fine.

Even our portlets deploy and start up in Liferay. However, as soon as you click a button to go somewhere, the troubles begin. All I have been able to gather is that the request which is generated has a new Session for some reason, so when Spring tries to get the FORM object off the session, it is not there.

Deploying the portlets on OAS is a little bit different. The first part of it is the same as with Tomcat... you either go through the Auto-Deploy field in the Admin portlet or drop it into the hot deploy directory. Liferay detects it and injects whatever code it needs and moves the war to the destination directory.

However, unlike Tomcat where it will automatically explode the war and start up the application, on OAS you must go through the control panel and follow a deploy process, which is mostly a click next to continue affair, although you must enter a name for the application and such.

I have been suspecting that OAS was the culprit, but unfortuantely I do not have much experience with it and have not been able to find any leads on what it might be.

[Jörg Heinicke]

However, as soon as you click a button to go somewhere, the troubles begin. All I have been able to gather is that the request which is generated has a new Session for some reason, so when Spring tries to get the FORM object off the session, it is not there.

This is still on Liferay and Tomcat? I can't see how you can mess up the session for the portlets. The session id in the portal and in the portlets is supposed to be the same - though the sessions are actually different if you have deployed the portlets as separate webapp. Tomcat has some cross-context properties in the context configuration. OAS might so as well.

Jörg

[vmaurik3]

Everything works fine in Tomcat... it is OAS where the sessions appear to be messed up.

The bizarre thing is that somehow EVERY request in OAS seems to have a new session. I put in log messages to print out the session id at various points. the id when the page loads the first time is "a", the id of the session on the action request is "b", and if there was any doubt that it was a brand new session, it has no attributes on it (I also had log statements to print these out).

As we are using sessionForm=true, it checks for the command object on the session, and not finding it, throws a PortletSessionRequiredException, which leads to the creation of yet another new session with id "c".

Whether "a" is still floating out there or somehow became invalidated, I am not sure.

Since everything "just works" in Tomcat, it makes it more frustrating.... what is different in OAS that could cause this behavior?

Is it possible that there is a setting which is off? Is it simply because the version with Tomcat came already bundled (and thus kinks such as this have been identified and eliminated already), whereas someone had to manually set up Liferay to work with Oracle and OAS?

I wish I could give you further insight but this is where we have been stuck.

[Jörg Heinicke]

Is it simply because the version with Tomcat came already bundled (and thus kinks such as this have been identified and eliminated already), whereas someone had to manually set up Liferay to work with Oracle and OAS?

Probably not. I have repeatedly set up "clean" Tomcat instances as downloaded from Apache (http://tomcat.apache.org) for Liferay and there are no special settings to make plain portlets working.

I never needed to set the cross-context properties of Tomcat. And the emptySessionPath I needed only for accessing the same session in some servlets creating graphs dynamically.

Anyway, when any exception is thrown from your portlets do you see Liferay in the stacktrace? And how do you create the links that lead to the requests? If the portal session itself is ok (otherwise you were forced to login after each request) something seems to be broken with the integration. But that's probably better asked on the Liferay forums (http://www.liferay.com/web/guest/devzone/forums) as you did already (http://www.liferay.com/web/guest/devzone/forums/message_boards/message/36356). Providing more details there might be helpful.

Jörg

[cmelgar]

What is the session tracking mechanism in use? I have seen this sort of problem under WebSphere Portal and that was due to a user's browser rejecting cookies.

[vmaurik3]

I'm pretty sure we are using cookies... I'm not sure how much information I can provide beyond that since I have not had my hands in that piece of our applciation at all.

Is there anything in particular I should look for to verify if that was the probelm?

@Jörg: There is no exception besides the one deliberately thrown by Spring when it didn't find the object on the Session. I have previously seen liferay in some stack traces... usually when there was an issue with a JSP or somehting along those lines.

[Jörg Heinicke]

There is no exception besides the one deliberately thrown by Spring when it didn't find the object on the Session.

This one must also have Liferay stuff in its stacktrace! Otherwise it's a strong hint that you access the portlets directly, not through the portal. That would also explain the unavailability of the session. But actually this would not explain a difference between Tomcat and OAS since it would also fail in Tomcat. I'm somewhat clueless what could be the reason ...

Jörg

[cmelgar]

I'm pretty sure we are using cookies... I'm not sure how much information I can provide beyond that since I have not had my hands in that piece of our applciation at all.

Is there anything in particular I should look for to verify if that was the probelm?


You can verify whether a cookie has been set by checking your browsers cookies. For example in Firefox if you look in Tools>Options>Privacy>Show Cookies you can see all the cookies set. Just check and see if there is a cookie from your host probably with a name JSESSIONID. If that has been set then it is unlikely this is your problem. On the other hand if the cookie hasn't been set then you will need to check your browser settings to see if it accepts cookies or alternatively use a tool like live http headers (http://livehttpheaders.mozdev.org/) to see if the server is trying to set a cookie (and is just being ignored by the browser).

[vmaurik3]

It does not appear that cookies are an issue here.

I discussed this a bit with the peson who originally was looking into the issue. His opinion is that the PortalSession is fine. (This was assumed since it was not asking us to login after each click) However, it appears that each request from the Portal to the Portlets is getting a new session.

Of course the question is still "Why?".

We are not doing anything "crazy". We defined our form action as such:

action='<portlet:actionURL>
<portlet:param name="action" value="search"/>
</portlet:actionURL>'

and we have input type images with name="_targetx" where x is the page number, as well as a submit button with name="_finish".

[Jörg Heinicke]

Cross-linking the threads: There seems to be a serious integration issue with OAS and Liferay (http://forum.springframework.org/showthread.php?t=41990).

Joerg

[vmaurik3]

Well, we had a bit of a breakthrough today. As it tuns out, if you add <private-session-attributes> to the portlet declaration in liferay-portlet.xml and set it to false, the session problem goes away.

This did not solve all of our problems, however, as we found that by setting this property, it causes our file download to break. (we put the file on the session and then create a resource url to a servlet which grabs the file off the session and opens the save file dialog box)

While investigating the above setting, we determined that it was still creating a new session each time, however, it was putting a wrapper around it that contained all the session information. Apparently when we made the call to the resource url, it used the bare httpsession which did not have the attributes on it.

To prove that this setting was interfering with the download, I deployed 2 of our portlets to tomcat/liferay and ran one with and one without the setting. The one where it was set to false, the download failed with a 405 error, and no attirbutes showed up in the log. On the one without the setting (and thus a true value), the download worked, and all of the attributes were on the session.

Through a sample app that a coworker wrote, we were able to determine that even Liferay bundled with Tomcat is doing the same thing, only Tomcat handles the cross-context stuff on its own, so we never lost the session info...

We are going to read through more of liferay's source and see if we can figure out how to handle the resource url issue.

[vmaurik3]

Alright, just to bring this whole thing to a close, we solved the file download issue as well today.

We are passing the filename as a parameter rather than putting/getting it off of the Session.

Everything seems to be working fine now, but time will tell if there are any other gotchas with the setting we added.