aspose file tools*
The moose likes Tomcat and the fly likes Session Replication Filtering Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Session Replication Filtering" Watch "Session Replication Filtering" New topic
Author

Session Replication Filtering

Thihara Neranjya
Greenhorn

Joined: Oct 12, 2011
Posts: 8
Hi,

Is there a way to limit what session attributes get replicated in a tomcat6 cluster? I tried the option called sessionAttributeFilter in DeltaManager. But it doesn't work.

<Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false"
notifyListenersOnReplication="true" sendAllSessions="true" sessionAttributeFilter="SessionMessages"/>

Has anyone used this? Or any other workaround like this??

Thanks.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

I couldn't even find any docs on this, but the very concept makes me uneasy. I have visions of session attributes spontaneously and inexplicably evaporating because a request went to the wrong server in a cluster.

What are you actually hoping to accomplish?


Customer surveys are for companies who didn't pay proper attention to begin with.
Thihara Neranjya
Greenhorn

Joined: Oct 12, 2011
Posts: 8
Tim I don't think it will happen as you imagine it, because this option will simply filter which session attributes are being replicated and which are looked over. My problem is related to a portal called liferay, I'm using the portal version bundled with tomcat and while clustering I need to make sure a specific session attribute is not replicated because replicating that attribute throws an NullPointer exception. This attribute is an struts class called OGNLValueStack which has all the struts Action classes inside. It's somehow being put in the session, presumably by the liferay portal.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

In other words, you already have session data spontaneously evaporating.

OGNLValueStack implements the Serializable interface, as all proper Session-scope objects must (and newer Tomcats insist). The session replication mechanism depends on being able to serialize session objects out of one server instance and into another.

Obviously, something is wrong here. Either 1) they lied about it being serializable, 2) there's a bug in the version of that class that you're using or 3) something's extending that class and isn't serializable.

For case #3, you can mark non-serializable properties as "transient" in the inherited class definition, although you should then be prepared to test and re-acquire/re-construct the transient child object(s) on each use. A classic example would be a JDBC Connection, which isn't serializable.
Thihara Neranjya
Greenhorn

Joined: Oct 12, 2011
Posts: 8
Disappearing is the wrong word in my opinion because we know the replication breaks after throwing an error.. The thing is OGNLValueStack has the struts action classes inside it.. It's not even supposed to be in the session, it's being put there by the said portal. There were some non serializable errors in the beginning but they are fixed now. The problem occurs when the other cluster nodes tries to read the OGNLValueStack (in DeltaManager). Other attributes aren't replicated because replication breaks with this attribute. So unfortunately the only solution I can think of is this.. If you got any other idea I'll be grateful to hear it.....
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

Well, just to repeat myself, session replication depends on ALL session objects being able to be serialized out (replicated) from one server and into another. Both the root objects and each and every non-transient object that they connect to. That is true regardless of the state of the application program, error or not.

As I said before, the OGNLValueStack claims that it honours that contract, since it implements the Serializable interface. So it's either defective in definition or implementation or someone lied.

But, discounting technical rigour, the real question seems to be whether that object should have been in session scope or not. If you say not, I can't disagree, since I haven't worked with it, but what I'd do is find out why it's being placed in session scope to begin with. While it's good practice for Struts action classes to not attempt to keep static or member properties in them, you can still make them Serializable if you must, even if they have no properties at all.

So the first thing I'd do is find out why the OGNLValueStack object is being stored at session context, and if it really should be. The second thing I'd do is determine if the internal objects for that class really have to be Struts action class objects as opposed to, say, serializable business POJOs that might be referenced by Struts action classes.

I realize that this isn't what you really want to hear, but the solution you're wishing for probably violates the J2EE standards and (more to the point) breaks if the application isn't properly configured in each and every participating server. Webapps should ideally be more self-contained than that.
Thihara Neranjya
Greenhorn

Joined: Oct 12, 2011
Posts: 8
Yes Tim I agree with you, But these solutions involve reworking the portlet which is what I am trying to avoid. This OGNLValue stack is in the session since the portal is exposing a different session to the portlet that need to be accessed by struts, or so it seems as far as I can tel. OGNLValueStack shouldn't be in the session but so far I have been unable to remove it without stripping away validation interceptor which breaks the functionality halfway.

Again the problem occurs even when I updated the xworks library, so can't really say its a bug in the library code right? I understand that it's not a very good solution but well it's the only one I could come up with without major rework taking place.

Thanks for your help Tim will post here if I manage to solve it. In a good way or a hackish, technical debt kinda way :-D
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

Good luck. There's definitely something wrong with this implementation, since there's no way to predict when a session might fail over (or be load-balanced) to another server, which means that properties that have been marked as stable would just up and disappear without notice at unpredictable times. That's not the way to make a robust app, and robustness is one of the key reasons for clustering in the first place. The fact that it would take extra work is immaterial, since "Git 'er Dun!" shouldn't be the overriding priority for a project that's this expensive.

If the fault lies not within application code, but in the infrastructure you're using, I strongly encourage you to nag the developers of that system to properly support serialization and clustering. If they won't, consider a platform that does. Otherwise this is going to be an ongoing nightmare.


 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Session Replication Filtering