• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Session Replication Filtering

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Thihara Neranjya
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.


 
reply
    Bookmark Topic Watch Topic
  • New Topic