Terracotta Discussion Forums

Thanks for the detailed description and the test app. I will look at it and should be able to report back to you soon.

regads,
Eugene Kuleshov

Please note that Spring context id (the long number you noticed) is calculated based on the application name + all names of the matching Spring configs. If any name of the Spring configs been changed or if new configs been added, the generated id will be different. See the following method for more details com.tcspring.DistributableBeanFactoryMixin.addLocation(String location)

However, there is parameter you can specify in tc-config.xml and explicitly name Spring context instead of using generated id. See XSD definition for tc-config.xml. For example:

Code:

<application>
   <spring>
     <jee-application>
       <application-contexts>
         <application-context>
           <root-name>myClusteredSpringContext</root-name>
           ...

regards,
Eugene

Configuration modules been designed to support reusable Terracotta configurations at the framework level. We'll have to implement new feature to provide application-level configuration for Spring but it is unclear how reusable it would be.

Can you please give us more specific examples of your application-specific constants, Spring configs and corresponding terracotta configuration for those that you had in mind?

Note that Spring has number of its own mechanisms to externalize and encapsulate application-level configuration details.

regards,
Eugene

cerdeira wrote:

Thanks for the response, is the name :( i change de name of my application in tomcat to jmx and works

You could have changed tc-config.xml to use your own name:

Code:

<jee-application name="foo">

Can you please check two things:

* the JAVA_OPTS env variable have -Xbootclasspath parameter in it
* the name of your web application is indeed "jmx" (i.e. it is deployed as jmx.war) and application context is loaded from the resource that matches pattern */applicationContext.xml

We just noticed that this problem most likely will go away if you will exclude org.springframework.orm.hibernate3.HibernateAccessor class from DSO instrumentation. We'll see if we can make it more transparent (so class won't need to be excluded), but in a mean time you can just excluded this class in tc-config.xml

regards,
Eugene

Can you please clarify what version of Spring you are using and also attach your web.xml, Spring context xmls and tc-config.xml.

In a mean time you could try to narrow down the issue, i.e. create smaller application by adding beans from your configuration one by one.

regards,
Eugene

aldarana wrote:

My application is built with spring 2.0 (session scope replication), I have clustered Struts view (module 1.1.0)

Simone, is your application storing anything into http session outside of Spring's session scoped beans?

I also wonder if you could extract some small subset of your application (probably stuff that is using scoped beans), that would allow to reproduce this issue?

regards,
Eugene

baront wrote:

I have put the whole of the initial file up. The test.cfm is in the root and is called cftest2ecfm700760098.class and the cfException thrown is cfException2ecfm1208463679.class

After looking at the mass of class files produced by the bloat that is coldfusion do you think there will be allot of gotchas within the coldfusion war? Or do you feel that terracotta will be able to provide http session replication ?

Thanks Nick. I've reproduced issue using your test case. Apparently CF generate some debug info for variables that aren't being used in the method code and I am pretty sure we can handle this case. Just give us little time. ;-)

regards,
Eugene

I don't think it is related to CDV-286, because that one wa specific to Java 6.

It sems like our instrumentation is choking on some classes compiled by ColdFusion (probably one compiled from resource \cfusion.war\test.cfm).

Can you please add the following system property to the JVM you are using to start Tomcat:

-Dtc.classloader.writeToDisk.initial=true

It will write all the classes before instrumentation to the folder at <user home>\initial (on windows - "C:\Documents and Settings\<user name>\initial"). Then please find class corresponding to the test.cfm up there and attach it here or on the bug report.

aldarana wrote:

create an AOP proxy as a separate bean and only make an original bean as clustered.

can you explain me this workaround? there I can see an example?

You can try something like this:

Code:

 <!-- a clustered bean -->
 <bean id="it.ktech.gedap.user.bean" class="it.ktech.gedap.view.user.WrapperUser" scope="session">
   <property name="manager" ref="it.ktech.gedap.interfaces.managers.ISecurityManager" /> 
 </bean>
 
 <!-- NOT clustered proxy for injecting into the other beans -->
 <bean id="it.ktech.gedap.user" class="org.springframework.aop.scope.ScopedProxyFactoryBean">
   <property="targetBeanName" ref="it.ktech.gedap.user.bean"/>
 </bean>

You may have to tweak some other properties. See following Spring classes for more details:

org.springframework.aop.scope.ScopedProxyFactoryBean
org.springframework.aop.scope.ScopedProxyUtils.createScopedProxy(..)
org.springframework.aop.config.AopNamespaceHandler

regards,
Eugene

Mike, please note that Terracotta runtime for Spring is automatically adding autolocking for all methods of beans that marked as clustered, as well as for their parent classes and classes referenced by fields. So, for many classes you don't need to specify includes and locking. The only exception is if Terracotta for Spring can't resolve classes (we don't match subtypes for the field values yet) or elements of the collections (though we do use generics info in Java 5). Those need to be included and locked manually.

However if there are classes included manually or have any locking configuration in tc-config, then this automatic autolocking is disabled (seems like it were your case).

Simone, the easiest way to deal with this issue is to extract all your session data into separate session-scoped bean (Spring 2.0) and then inject that bean into your prototype or even into a singleton bean that would have all your DAO and other dependencies. Though for the latter don't forget to wrap bean into session-aware proxy, so singleton bean will deal with the right instance.

If you don't want to use session-scoped beans then it is still a good idea to extract state into a separate class and only store that class into the session. Otherwise you'll have to figure out all transient fields for DSO (all DAO and such is not clusterable, since it has links to local resources or databases) and also restore them when object is pulled out of the session.

regards,
Eugene

vijay wrote:

Currently Terracotta publishes a particular event to all clients within a logical context. But we had a requirement of publishing that event to one of the clients within that logical context and the other clients' invoker thread won't even be notified for that event. This change was specific to our requirement.

That is correct and it is done because it is hard for us to declaratively specify which clients need to receive what events. Actually, it is possible do something like that if you'll directly use DMI, then events will be distributed to the clients who hold the instance on which distributed method is invoked.

To make it more flexible for the client code, you actually don't have to use DMI, and instead can create LinkedBlockingQueue per event consumer and hook a thread or the thread pool that would pickup messages from the queue. Then you can register those queues in the event creator, so it would just add each event to all registered queues. Then in order to handle situation when client went down, event producer should also subscribe to cluster notification and unregister queues from clients that went down.

vijay wrote:

Actually I am trying to publish an event on a single context that is the intended reciever of the event. For that I had to make some changes in the ManagerUtil, ManagerImpl & DistributedMethodCallManagerImpl classes.

Are there any works going on this particular context?

How it is different from the functionality that Terracotta for Spring already provides? http://terracotta.org/confluence/display/docs1/Spring+Quick+Start#SpringQuickStart-Events