Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi – we are trying to simply get session replication working with JBoss 4.0.5 without success.

Both the webapp instances correctly show up in the admin console as clients. However there is no entry under ‘Roots’ within admin console.

I am assuming that under the admin console ‘Roots’ we should see something like tc:session_<appname> like is seen in the admin console for the demos.

TC server is running. I assume the env vars to run JBOSS are correct (we set them with dso-env.bat) since the tests nodes are correctly shown as clients under admin console.

So I assume its something wrong with the tc-config.xml. We also tried adding explicit roots (even though we are only trying session replication) but they do not appear under admin console either.

What are we doing wrong??

Thanks for your help..

Config:-

<?xml version="1.0" encoding="UTF-8"?>
<tc:tc-config ..
<application>
<dso>
<instrumented-classes>

<include>
<class-expression>*..*</class-expression>
</include>


<exclude>com.aplia.platform..DAO</exclude>

<exclude>org.apache.coyote..*</exclude>
<exclude>org.apache.catalina..*</exclude>
<exclude>org.apache.jasper..*</exclude>
<exclude>org.apache.tomcat..*</exclude>
</instrumented-classes>

<web-applications>
<web-application>frontend</web-application>
<web-application>root</web-application>
</web-applications>
<roots>
<root>
<field-name>com.aplia.platform.payment.CoursePaymentHistoryImpl.professor</field-name>
<root-name>Aplia</root-name>
</root>
</roots>
</dso>
</application>
</tc:tc-config>

Hard to tell, here are a few guesses:

1) What web app are you clustering? I see you have specified the root webapp, but this should be specified using ROOT, not root. I am fairly certain, though not 100% sure, that the spec is case sensitive.
2) Make sure to make a request. I think the root is not created until at least one request is submitted.
3) How are you managing the tc-config.xml? Are the clients reading it from disk or from the server? If the latter, are you starting the server using the tc-config.xml you sent, or just a blank tc-config?
4) Just out of curiosity - did you use the configurator to create that tc-config, or by hand?

Thanks for the reply..

1) whoever built this app originally decided in their wisdom to call the war root.war so I think lowercase root should be right. The app (which is deployed as and ear) actually includes two war files as modules. The first is root and the 2nd is called frontend which is why we also included that in the tc-config.xml.

2) yes I did that. I noticed in the demos that the roots only were displayed in the admin console once the first request was serviced by the webapp.

3) for the moment the tc-config.xml is loaded by the client from the local disk. Both webapp instances have a copy of the same config.

4) the config was copied from the examples and modified by hand

I noticed in the client log some mesasges like:-

[main] ERROR com.terracottatech.dso - Refusing to instrument CGLIB generated proxy type com.aplia.platform.site.Course$DAO$$EnhancerByCGLIB$$832003d9 (CGLIB terracotta plugin not installed)

This is a JBOSS app but also uses Spring for some DAO's. Initially the instrumented app generated class cast exceptions when instancing beans from the
Spring context so we tried to exclude those beans from tc instrumentation to avoid tc messing with the CGLIB wrapped Spring beans. We used <exclude>com.aplia.platform..DAO</exclude> -

<instrumented-classes>
<include>
<class-expression>*..*</class-expression>
</include>
<exclude>com.aplia.platform..DAO</exclude>

Excluding these classes gets us past the class cast exceptions and we dont reference any session attributes in those Spring beans so this approach should work?

I tried a few more things just now but still drawing a blank..

1) just to confirm.. the name in the <web-application> tab should be exactly the name of the deployed war file - correct? So if I deploy xyz.war my session config should be <web-application>xyz</web-application>

2) even if the war file name is wrong why dont defined <root>'s work? (i.e. show up under the Roots in admin console) e.g. the test we did
<root>
<field-name>com.aplia.platform.payment.CoursePaymentHistoryImpl.professor</field-name>
<root-name>Test</root-name>
</root>
does not show up.

Any other ideas or guesses most welcome. Is there any other more detailed data that would help resolve the issue?

Thanks..
David

David,

I'm not sure, but maybe we could start with a simple example - take for example the cart application and deploy it and see if you can get it to show a root? Then we'll work from there?

Answering your followon Q's:

1) yes, that is correct
2) this has me stumped. The only thing I can think of is that the root won't show up until at least one instance of the class is loaded so again I would say you would have to make sure to make not just a request, but one that loads that particular class.

Taylor - yours was a good suggestion and when I deployed Cart it worked immediately. Its session showed up in admin console and proves that the JBOSS config/startup is 100% good.

So there must be something about the structure of our web app that TC does not like. So I started ripping everything (filters, servlets etc etc) out of web.xml and finally got the session to show up with a minimal web.xml.

Tomorrow I will have to start putting everything back into web.xml until I find out what breaks it. Are there any known issues with stuff in web.xml that may cause problems..otherwise I'm into a lengthy spell of trial and error.

thx for your help..

David

David,

Glad to see some progress. I can't think of anything in particular. Are you doing anything funny with the SessionManager in a filter perhaps?

Taylor - I have more progress and have the app at least starting and its session showing in admin console. But any attempt by the app to access the session fails with exceptions like -

java.lang.IllegalStateException: This session is invalid
at com.terracotta.session.SessionData.checkIfValid(SessionData.java:96)
at com.terracotta.session.SessionData.getAttribute(SessionData.java:152)
at com.aplia.platform.ApliaSession.getUser(ApliaServlet.java:971)
at com.aplia.platform.ApliaServlet.service(ApliaServlet.java:464)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)

--OR--
java.lang.IllegalStateException: This session is invalid
at com.terracotta.session.SessionData.checkIfValid(SessionData.java:96)
at com.terracotta.session.SessionData.getAttribute(SessionData.java:152)
at org.apache.jsp.includes.broadcast_jsp._jspService(broadcast_jsp.java:47)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)

Any idea what this is about?
BTW -Thanks for all your help so far..David

Well, one thought is that the session has either not been created, or has been invalidated in the same request (and then re-created). Unfortunately the latter is a bug (that was just discovered several days ago on this thread: http://forums.terracotta.org/forums/posts/list/280.page)

I'll have a chat with the experts on the Sessions implementation and see if they can jump in and provide more thoughts on what can trigger that Exception.

Taylor - so I dug into the code and found, yes, the session was being invalidated explicitly by the code. So it looks like I've hit the same bug.

What sort of time frame could we expect to see a resolution for this?

David

David,

Sorry I didn't get you a reply - today was hectic. Anyway, we are still looking into that problem, so we don't yet know the extent of fix. Of course I would like to fix it right away, but I would like to fix everything right away.

Bug fix priorities are determined by the severity of the error, and the number of the deployments that it affects. If it were very highly prioritized, say for a production deployment, then we could add it to the 2.3 line as a 2.3.1 patch, and then roll it in to the 2.4 line. Also if it is blocking people like yourself evaluating Terracotta, then it is also a very high priority fix, but would more likely go in to the trunk.

Taylor - thanks for the update. Please let me know after the engineers have analyzed the extent of the problem.

We are pretty interested in using TC but this issue would probably be a show stopper for us for the moment.

Thanks,
David

Hi David,

Were you able to discover what extra bits in your web.xml were causing the terracotta session root to not show up? I can't imagine why, but I would think if anything was going to screw us up, it would session event listener classes (<listener> element in web.xml).

You asked earlier about what should be in the <web-application> section of tc-config.xml. What you want to list in there is your web app's context path, which can be (but usually isn't) different than the name of your war file. For example, if your URLs look like http://<host>/mypath/...., then "mypath" would be the appropriate value. If you're using the default/root context, then the magic value "ROOT" would be specifed in tc-config.xml. Not sure if this is useful info at this point, but I thought I'd share.

Tim - I think it ended up being a newbie mistake..
the app has multiple war files and the <application> in application.xml has

<web-uri>mywar</web-uri>
<context-root>/mycontext</context-root>

So it appears that in tc-config.xml rather using the 'mywar' name we must use the context name 'mycontext'

<web-applications>
right=<web-application>mycontext</web-application>
wrong=<web-application>mywar</web-application>

However the problem with an application that invalidates the session is still an issue for us. As per the discussion previously I'm hoping Taylor will update us on this issue resolution as he knows more..

davidm wrote:

However the problem with an application that invalidates the session is still an issue for us. As per the discussion previously I'm hoping Taylor will update us on this issue resolution as he knows more..

I haven't forgotten...there is not anything to report as of yet.

The issue with creating another session after invalidate() should be resolved in the 2.4 branch (as of revision 3923)

Any nightly build past that revision, or the next 2.4 stable release will contain the fix.

http://svn.terracotta.org/fisheye/changelog/Terracotta/?cs=3923