Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

kishanov wrote:

Do you plan to add this functionality in the future releases of plugin?

It would require some kind of listener (e.g. on specific port or better on tcp broadcast) and use wrapper around your Java process that would terminate it on a command from the listener. As Taylor already suggested you can submit request for that in JIRA, or you can implement such wrapper yourself and use it to start your applications or even contribute it back to Terracotta Maven plugin. ;-)

regards,
Eugene

Please see documentation at http://forge.terracotta.org/releases/projects/tc-maven-plugin/configuration.html#Choosing_Terracotta_runtime_version

First of all you need to specify terracotta dependency in <plugin><dependencies> and also make sure that you are using Maven 2.0.9 or later.

regards,
Eugene

You can only terminate web application servers launched with cargo. Java processes started from a main class can't be terminated this way.

regards,
Eugene

spindle wrote:

Eugene,you said -"I don't think you can"-,if it is so,this means that we can't share the same bean between two different web applications in a container(like Tomcat) with terracotta?

Without fix for CDV-112, the only workaround currently available is to put common shared classes under some common classloader, such as in system classpath or in Tomcat's common ($CATALINA_HOME/common/lib dir) or shared ($CATALINA_BASE/shared/lib) classloaders.

Another option that may work (I haven't tried it), is to put them in 3rd web app and call that web app from the first two. It is somewhat a hack, but you can access other webapp contexts trough ServletContext.getContext(uripath). I am pretty sure you can obtain RequestDispatcher and include content from that web app, but you might be also able to load classes from the classloader of the returned servlet context and use it as a bridge to the common API.

regards,
Eugene

I don't think you can, but please do ask this question on that JIRA issue.

regards,
Eugene

If I understand this correctly, you are hitting DSO limitation related to classloading. In other words, currently you need to put all shared classes into some common classloader that will have same DSO name across all nodes (e.g. Tomcat's shared classloader or system classpath).

I've described similar issue at [1] and then it been tracked in [2], please comment there, because it doesn't seem like current solution addressed your case.

regards,
Eugene

[1] https://jira.terracotta.org/jira/browse/CDV-81#action_18431
[2] https://jira.terracotta.org/jira/browse/CDV-112

Thanks Ross.

regards,
Eugene Kuleshov

Ross, the tim module on the Terracotta Forge suppose to replace stuff from jetty contrib. Please submit JIRA for Forge and link codehaus JIRA in there.

regards,
Eugene Kuleshov

Darin, how exactly Terracotta for Spring is used in this application?

A simple test app would make it much easier to investigate this issue. Some more details about duplicate JSESSIONID issue and custom sessionid.name would also help to understand the problem.

I haven't used JCaptcha before, and was under impression that it generates captcha image/text (which don't need to be clustered) and stores corresponding answer into http session, so in theory it should be completely transparent as long as session is clustered properly.

Out of curiosity, why do you bounce user to a different server on each request? If you bring him to the same server every time it would reduce amount of data for replication.

regards,
Eugene Kuleshov

ryan wrote:

Turns out the problem was related to a configuration error on my part. I was starting the server with the following command:

bin/start-tc-server.sh $TC_CONFIG_FILE

(notice the missing -f). I did not notice that the server started with the default configuration and not _my_ configuration. When the tomcat client retrieved the configuration from terracotta it received the default configuration and obviously did not share a spring context.

Right, such typos are hard to notice.

ryan wrote:

Thanks for the tips on debugging the spring context loading, I changed my config to '*SpringConfig-Database.xml' which works just fine however I thought I would go a step further and try '*SpringConfig-*.xml' which did not work. I am not sure if this is because two wildcards in the same path are not supported or because the configuration expects the same number of entries as context files (and not just one wildcard express to match them all).

You can use *.xml, but we don't support wildcard in the middle (only *, *foo, foo* and *foo* wildcards). It is briefly mentioned here. I've added those tips to the FAQ linked from the terracotta.org page.

ryan wrote:

I was able to verify the includes were not required and are picked up automatically based on the classes in the distributed-events section. I must have added them at some point trying to fix some other problem and never went back and looked to see if they were needed. I left the transients in because I do not wish to cluster those properties.

I think transients are registered automatically as well.

ryan wrote:

enable-location-info was something i found in the forum which looked to me like it would help me figure out why my spring contexts were not being found by terracotta. It sounds like I misinterpreted the meaning however I was not able to find documentation on this feature.

This was sort of intentional because feature is targeting rather uncommon case.

ryan wrote:

It is unfortunate matching application events based on subtypes is not supported. It would be nice to have an event class denote it is clustered without having to edit the terracotta config (I may take your suggestion and put all clustered events in their own package so I could do com.foo.clustered.*).

I have to look at this again, we should have new framework available since this feature been implemented. If you are interested in such feature, please open JIRA issue.

ryan wrote:

This is my second project setting up terracotta and while the second time was a lot easier (terracotta 2.5 is a lot nicer than 2.3 and I am more familiar with terracotta concepts then I was on the first project) I found myself looking for information that still does not seem to be available (or its difficult to find). Three examples from this thread are:

- Knowing what wildcards are supported/required for loading spring contexts
- Understanding what enable-location-info does (it did not appear to be in the configuration reference)
- Subtypes are not supported on distributed-events.

I think it would be very helpful if the configuration reference was a lot more verbose in describing what syntax is available on each field. Also it would be nice to have more examples of the syntax (again with a clear list of where that syntax can be used) so there is a lot less trial and error to determine what you can and can't do on each field.

I am happy with the amount of time it took me to setup terracotta but it would have been many hours less if I was able to find the information I needed to figure out why my configuration was not working the way I thought it should.

I am glad to hear that you see improvements since the last version. I'll send a note to our documentation team about your points. Thanks for your patience on tracking those issues.

regards,
Eugene Kuleshov

Please don't use <enable-location-info>true</enable-location-info>, unless you are absolutely have to.

regards,
Eugene Kuleshov

Please note that latest version of the Terracotta Maven plugin provides integration with Cargo and allows to start Tomcat and potentially other application servers supported by Terracotta with enabled clustering.

regards,
Eugene Kuleshov

Ryan,

The problem is most likely with the matching pattern you've used for your resources. Depends how those configs are loaded (i.e. from web-inf folder in your web app or from the classpath) web app server or Spring framework could add some prefixes for the actual resource names, like classpath:SpringConfig-Repositories.xml or /SpringConfig-Repositories.xml and in result paths you've specified won't match.

You can enable debug logging for com.tcspring and org.springframework category, either in your own web app (i.e. using log4j configuration) or in Tomcat global logging settings at <tomcat home>\conf\logging.properties

Then you should see the actual application name that is being used and the actual resource names used at the runtime and can make sure they do match with paths you specified in tc-config.xml. For example:

Code:

 2007-12-27 18:33:43,507 INFO [com.tcspring.ApplicationHelper] - Application name Tomcat.shared
 2007-12-27 18:33:43,804 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/servlet.xml]
 2007-12-27 18:33:45,710 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/dao.xml]
 2007-12-27 18:33:45,804 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/services.xml]
 2007-12-27 18:33:46,273 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/datasource.xml]
 2007-12-27 18:33:46,335 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/cache.xml]
 2007-12-27 18:33:47,257 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/captcha.xml]
 2007-12-27 18:33:47,320 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/validators.xml]
 2007-12-27 18:33:47,351 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/storedprocs.xml]
 2007-12-27 18:33:47,648 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/pagers.xml]
 2007-12-27 18:33:47,695 INFO [com.tcspring.DistributableBeanFactoryMixin] - 09080A0C0905030C0E05070F0805050A Matching locations:[/WEB-INF/spring/servlet.xml, /WEB-INF/spring/dao.xml, /WEB-INF/spring/services.xml, /WEB-INF/spring/datasource.xml, /WEB-INF/spring/cache.xml, /WEB-INF/spring/captcha.xml, /WEB-INF/spring/validators.xml, /WEB-INF/spring/storedprocs.xml, /WEB-INF/spring/pagers.xml]
 2007-12-27 18:33:47,695 INFO [com.tcspring.DistributableBeanFactoryMixin] - 09080A0C0905030C0E05070F0805050A Context is distributed

Note that you can use patterns like <path>*SpringConfig-Database.xml</path> to specify matching spring configs.

Here are few more notes:

- you shouldn't need includes and transients for spring event classes as they should be included automatically. isb't that the case?

- <enable-location-info>true</enable-location-info> is not recommended, unless you are creating multiple spring contexts from the same configs and need to have unique identity for each of those contexts (i.e. don't want them to have the same shared beans)

- matching on subtypes of application context events is indeed not
supported, but raw pattern matching (i.e. *.foo and foo.*) is supported)

regards,
Eugene Kuleshov

Shake wrote:

Yes, tried that already:Code:

      <roots>
         <root>
           <field-expression>* org.joda.time.DateTimeFieldType org.joda.time.DateTimeFieldType.*</field-expression>
           <root-name>theName</root-name>
         </root>
       </roots>

Indeed. It seems like parser doesn't like when * is used in the modifiers slot. I've tried this variant and it is at least accepted by the expression parser:

Code:

<field-expression>private static final org.joda.time.DateTimeFieldType org.joda.time.DateTimeFieldType.*</field-expression>

regards,
Eugene Kuleshov

Shake wrote:

... Since I could't find a valid field-expression, I had to add every single field...

Documentation for the expression language is here. So you can try something like this:

Code:

<field-expression>* org.joda.time.DateTimeFieldType org.joda.time.DateTimeFieldType.*</field-expression>

regards,
Eugene Kuleshov