Terracotta Discussion Forums

Hello,

Recently I've been working to get Terracotta up and running with a Tomcat CometProcessor but haven't had much success. I've seen http://forums.terracotta.org/forums/posts/list/3308.page and the jira link in the post but it seems from looking at the code that the event method of the valve method had been implemented but that it hadn't been confirmed that tomcat's comet implementation works with terracotta.

What I'm observing locally is that in a normal Servlet/Filter when one retrieves a session ((HttpServletRequest)request).getSession(true).getId()) from a request it's actually calling the SessionRequest wrapper which executes a lot of the web sessions magic goodness and a id/cookie will be returned that has a distinctive pattern with a dot digit suffix. (Y0vu13kyOdSUuCUJu8IR.53 for example)

The problem I'm seeing with the CometProcessor.event call is that the CometEvent passed in does not include the SessionRequest wrapper on the HttpServletRequest retrieved from the event. So when I then go to retrieve the session the standard tomcat implementation is called and I see a id/cookie like B247027B279588340131B70ECB298409)
Code:

 	public void event(CometEvent event) throws IOException, ServletException {
 	    HttpServletRequest request = event.getHttpServletRequest();
 	    System.out.println("Begin for session: " + request.getSession(true).getId());

If I print out the request.toString for the CometProcessor case I see that the object is the standard tomcat request facade:
org.apache.catalina.connector.RequestFacade@2bc674d8

For the standard servlet/filter it's a SessionRequest.
com.terracotta.session.SessionRequest@6d75ae09

It seems like a fix for this would be to wrap a proxy around the method org.apache.catalina.connector.Request.getEvent() that returns a wrapper around the CometEventImpl it returns. That wrapper would add the terracotta SessionRequest around the request CometEvent returns. BaseRequestResponseFactory seems like a good place to add this code.

I'm working on implementing this but thought I'd post to see if I'm heading in the correct direction and/or if I'm missing something obvious.

Thanks in advance!

-Mark

I've implemented a solution that appears to be working.

The current fix is to the 1.0.1 version of terracotta-sessions and impacts the following files.

Code:

 //terracotta-forge/projects/terracotta-session/tags/release-1.0.1/tomcat/src/main/java/org/terracotta/session/TerracottaTomcat60xSessionValve.java
 //added
 public void event(Request arg0, Response arg1, CometEvent arg2) throws IOException, ServletException {
   realValve.event(arg0, arg1, arg2);
 }

Code:

 //terracotta-forge/projects/tim-tomcat/tags/release-2.1.2/tim-tomcat-5.5/src/main/java/org/terracotta/modules/tomcat/tomcat_5_5/SessionValve55.java
 // added at line 83
 sReq55.setSessionResponse(sRes55);

Code:

 //terracotta-forge/projects/tim-tomcat/tags/release-2.1.2/tim-tomcat-5.5/src/main/java/org/apache/catalina/connector/SessionRequest55.java
 //added
 public CometEventImpl getEvent() {
   if (event == null) {  			
     event = new CometEventImpl(this, sessionRes);
   }
   return event;
 }

For terracotta-forge/projects/tim-tomcat/tags/release-2.1.2/tim-tomcat-5.5/pom.xml I replaced catalina dependency with 6.0.29 and added it as the first dep. If I port this to trunk I'd look to incorporate the 6.X specific code into the tim-tomcat-6.0 module.

I'm planning on upgrading to the latest version of terracotta in the near future and would be happy to contribute a patch if others are interested.

-Mark

Hi mark, thanks for the digging into this stuff!

The code changes look reasonable as we do have to make sure the unwrapped request isn't leaked out to anyone who want to use it to retrieve a session.

I haven't spent enough time looking at how comet/event work to say if this is all we need to do but it is encouraging that things appear to be working.

If the changes are really just what you described here I don't know that we need to go though the process of accepting a patch for it. It actually takes some paperwork (on your end) to make that happen

I'm sure signing the paperwork won't be a problem. I'll pm you with my contact details.

Hi,

I am wondering why this patch was never applied. Is there any technical reason for it?

Thanks in advance for your response.

Cheers
Jan

No real technical reason for not getting this change applied. In general though I'm not one to commit anything without writing any tests around it. Since it would take me some time to figure out how to write a test for this it hasn't happened and the management powers that be aren't asking for "comet support" nothing has happened.

I'll have another look at this change though and maybe commit it without any explicit comet tests. hate to have it just sit here doing nothing

Well that didn't take too long before I felt a little uneasy committing anything. What I don't quite feel good about is the extended lifetime of the request/response objects, and what might need to happen on a timeout.

I'm afraid that until proper feature support is requested by PM here I'm going to need to leave our valve throwing UnsupportedOperationException

Hi Teck,

thanks for your reply. Throwing an UnsupportedMethodException breaks in my case the comet application. The long running threads are terminated and so not long running anymore ;-).

We just applied a small patch to Terracotta which gives us the possibility to run the application. But there are two points where we had to fix something in a very dirty way in order to avoid exceptions to be thrown.

I am more than willing to send you the patch.

Cheers
Jan

I'm looking into this issue right now. Would you post the patch here?

Hi,

find attached two patch files with the changes I applied to get Terracotta working with Comet events.

The patch for the session TIM is to avoid exceptions. If you don't apply this patch you will experience some exceptions that broke my application. This patch is definitivly not a fix for these problems but maybe a hint ...

Cheers
j.

Thanks for the patch. I'm testing it out right now. Even though the app seems to work well, there's an exception in Tomcat log

SEVERE: An exception or error occurred in the container during the request processing
java.lang.RuntimeException: java.io.NotSerializableException: org.terracotta.modules.tomcat.tomcat_6_0.SessionRequest60
at com.terracotta.session.SerializedAttributeStore$SerializedAttribute.<init>(SerializedAttributeStore.java:98)
at com.terracotta.session.SerializedAttributeStore$SerializedAttributeWithCache.<init>(SerializedAttributeStore.java:141)
at com.terracotta.session.SerializedAttributeStore.put(SerializedAttributeStore.java:60)
at com.terracotta.session.SessionData.bindAttribute(SessionData.java:455)
at com.terracotta.session.SessionData.setAttributeReturnOld(SessionData.java:322)
at com.terracotta.session.SessionData.setAttribute(SessionData.java:313)
at org.apache.catalina.valves.CometConnectionManagerValve.invoke(CometConnectionManagerValve.java:265)
at org.terracotta.modules.tomcat.tomcat_5_5.SessionValve55.tcInvoke(SessionValve55.java:100)
at org.terracotta.modules.tomcat.tomcat_5_5.SessionValve55.invoke(SessionValve55.java:85)
at org.terracotta.session.ModernTomcatSessionValve.invoke(ModernTomcatSessionValve.java:66)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:886)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2256)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

I never applied the org.apache.catalina.valves.CometConnectionManagerValve. This might be the reason that we never experienced this exception.

Thanks for the tip. Do you happen to have a comet example that I could try?

Hi,

maybe you can use one of the Atmosphere examples. Find here an article explaining: http://jfarcand.wordpress.com/2010/06/15/using-atmospheres-jquery-plug-in-to-build-applicationsupporting-both-websocket-and-comet/

And here you can download an example (just add the TerracottaValve in the context.xml after expanding the war file):
http://oss.sonatype.org/content/repositories/releases/org/atmosphere/samples/atmosphere-jquery-pubsub/0.7.2/atmosphere-jquery-pubsub-0.7.2.war

If you want to test the application do not forget the trailing slash:
http://localhost:8080/atmosphere-jquery-pubsub-0.7.2/

Hope this helps.

Cheers
j.

Thanks for the demo. It works well when I tested it. I've sent you a PM regarding the contributor agreement to allow us to use the patch.