Author |
Message |
09/18/2006 10:03:13
|
mouadbox
neo
Joined: 09/13/2006 06:58:37
Messages: 8
Location: MGP
Offline
|
Hi All,
I looked to the samples provided within TC4Spring installation package.
All the samples are TOMCAT server related.
So is TC4Spring providing clustering options just for servers based applications ?
Or does TC4Spring support wide range for spring based applications ?
|
|
|
09/18/2006 11:18:20
|
tgautier
seraphim
Joined: 06/05/2006 12:19:26
Messages: 1781
Offline
|
mouadbox wrote:
Hi All,
I looked to the samples provided within TC4Spring installation package.
All the samples are TOMCAT server related.
So is TC4Spring providing clustering options just for servers based applications ?
Or does TC4Spring support wide range for spring based applications ?
Hi Mouad.
In fact TC4Spring can cluster any kind of Spring application, including a POJO based application.
The configuration is not any different than what we have discussed in our other thread - in other words you can use an XML Application Context to instantiate an Application Context from within a Main method, and call "getBean()" to get access to the beans.
When you are running with Terracotta, as discussed before, if those beans are declared in the Terracotta config file, they will be shared across VM instances.
Best Regards,
Taylor
|
|
|
09/28/2006 10:18:00
|
Alex Kozlenkov
neo
Joined: 09/28/2006 06:22:46
Messages: 7
Offline
|
Hi,
I am attempting to write a simple test using standalone Spring Java application along the lines of the master-worker example on serverside (the listings published tehre are incomplete).
Unfortunately, the context so far does not appear to be distributed.
Code:
INFO: Loading XML bean definitions from class path resource [context.xml]
28-Sep-2006 18:13:01 com.tcspring.DistributableBeanFactoryMixin determineIfClustered
INFO: 070A070D040D0C0C0A0E0F0B0E090708 Context is NOT distributed
Here is my configuration file:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<tc:tc-config xmlns:tc="http://www.terracottatech.com/config-v1">
<system>
<jdbc-enabled>false</jdbc-enabled>
<dso-enabled>true</dso-enabled>
</system>
<application>
<spring>
<jee-application name="*">
<application-contexts>
<application-context>
<paths>
<path>*/context.xml</path>
</paths>
<beans>
<bean name="master" />
<bean name="queue" />
</beans>
</application-context>
</application-contexts>
</jee-application>
</spring>
</application>
</tc:tc-config>
Any ideas what I am doing wrong or perhaps you could post a Terracotta Spring example for standalone applications? To clarify, two instances of my application run correctly but the objects do nota appear to be shared.
Cheers,
Alex
|
|
|
09/28/2006 10:24:16
|
tgautier
seraphim
Joined: 06/05/2006 12:19:26
Messages: 1781
Offline
|
Alex,
Would you mind posting your context.xml file?
Thanks,
Taylor
|
|
|
09/28/2006 12:10:13
|
Alex Kozlenkov
neo
Joined: 09/28/2006 06:22:46
Messages: 7
Offline
|
Here goes (the usual Spring DTD stuff omitted):Code:
<beans>
<bean id="master" class="com.betfair.terracotta.tasks.Master">
<constructor-arg ref="queue"/>
</bean>
<bean id="queue" class="java.util.concurrent.LinkedBlockingQueue"/>
</beans>
|
|
|
09/28/2006 12:20:12
|
tgautier
seraphim
Joined: 06/05/2006 12:19:26
Messages: 1781
Offline
|
I think it may be that your regex for the context xml is not matching - try context.xml not */context.xml.
Taylor
|
|
|
09/28/2006 12:31:08
|
Alex Kozlenkov
neo
Joined: 09/28/2006 06:22:46
Messages: 7
Offline
|
Taylor,
Many thanks for the CORRECT suggestion. The beans in the context get picked up now but the code blocks which is likely an issue with what I'm doing. I'll try dumbing down the example to make sure it works as expected. I'll let you know how it goes. BTW we've got somebody from TC visiting tomorrow in our company but unfortunately I won't be able to meet the guy.
Cheers,
Alex
|
|
|
09/28/2006 13:59:11
|
Alex Kozlenkov
neo
Joined: 09/28/2006 06:22:46
Messages: 7
Offline
|
Taylor,
I'm following Jonas' paper and making only the queue bean shared. Running a single instance of such application stops after:
Code:
28-Sep-2006 21:52:59 com.tcspring.DistributableBeanFactoryMixin registerDistributedBeans
INFO: 0304090E050B0C0C080B07070C060609 registering transient fields for queue java.util.concurrent.LinkedBlockingQueue
Any ideas? Posting a working Jason's application would be very helpful.
Thanks==Alex
|
|
|
09/28/2006 14:14:05
|
tgautier
seraphim
Joined: 06/05/2006 12:19:26
Messages: 1781
Offline
|
Alex,
As I mentioned in the PM I sent to you, I will have a demo application up very soon.
In the meantime, can you determine if you are executing your client code or do you stop before you get to the main method? If you are executing your client code I would suggest putting some printlns in to see exactly where you are stopping up.
Taylor
|
|
|
09/28/2006 14:31:53
|
Alex Kozlenkov
neo
Joined: 09/28/2006 06:22:46
Messages: 7
Offline
|
This doesn't reach the println call:Code:
String contexts[] = { "context.xml" };
ApplicationContext ctx = new ClassPathXmlApplicationContext(contexts);
System.out.println("**************");
|
|
|
09/28/2006 14:42:36
|
tgautier
seraphim
Joined: 06/05/2006 12:19:26
Messages: 1781
Offline
|
What if you take the master bean out?
|
|
|
09/29/2006 03:14:55
|
mouadbox
neo
Joined: 09/13/2006 06:58:37
Messages: 8
Location: MGP
Offline
|
Hi All,
It would be very helpful, if TC Team could provide a getting started manuel, or at least tutorial on standalone application.
Mouad
|
|
|
09/29/2006 07:06:09
|
Alex Kozlenkov
neo
Joined: 09/28/2006 06:22:46
Messages: 7
Offline
|
Totally agreed about the manual. Even more important is to have a simple example working for starters. I can't get past a few exceptions now.
Basically, my example applications write to the same bean called "results" that is a LinkedBlockingQueue. I've found that using some other collections like CopyOnWriteArrayList did not work at all.
Now one thing that happens and really puzzles me is that the bean still keeps its state after all applications using it are already finished. Starting an application four times in a row exhausts the maximum number of connections for the evaluation copy and stops until I restart the server--perhaps there is another reason for this behaviour.
Moreover, I encountered the following exception while the code runs to completion on second run and after:Code:
SEVERE: 0D040F050C0B04060E0F02060E070E0C Error when copying transient fields to results
java.lang.IllegalAccessException: Field modification through reflection for non-physical shared objects is not supported!
at com.tc.util.FieldUtils.set(FieldUtils.java:169)
at java.lang.reflect.Field.set(Field.java)
at com.tcspring.DistributableBeanFactoryMixin.copyTransientFields(DistributableBeanFactoryMixin.java:362)
at org.springframework.beans.factory.support.AbstractBeanFactory.copyTransientFields(AbstractBeanFactory.java)
at com.tcspring.GetBeanProtocol.copyTransientFields(GetBeanProtocol.java:131)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory_2_674776996__798057117_599532254___AW_JoinPoint.invoke(Unknown Source)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.aw$original$_AW_$createBean$_AW_$org_springframework_beans_factory_support_AbstractAutowireCapableBeanFactory(AbstractAutowireCapableBeanFactory.java:378)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory_1_674776996_662555251___AW_JoinPoint.proceed(Unknown Source)
at com.tcspring.GetBeanProtocol.beanNameCflow(GetBeanProtocol.java:82)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory_1_674776996_662555251___AW_JoinPoint.proceed(Unknown Source)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory_1_674776996_662555251___AW_JoinPoint.invoke(Unknown Source)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:233)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:145)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:283)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:313)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:87)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:72)
at com.betfair.terracotta.tasks.Application.<init>(Application.java:19)
at com.betfair.terracotta.tasks.Application.main(Application.java:61)
That is all that is output to stderr. Would be really good if we could get to the bottom of it guys.
Cheers==Alex
|
|
|
09/29/2006 10:08:59
|
tgautier
seraphim
Joined: 06/05/2006 12:19:26
Messages: 1781
Offline
|
mouadbox wrote:
Hi All,
It would be very helpful, if TC Team could provide a getting started manuel, or at least tutorial on standalone application.
Mouad
Mouad,
You are absolutely right. We are working very hard on just those things I am glad you think they will be useful.
I'll make sure to post in these forums when they become available - actually I think it's safe to say that the Master/Worker pattern that Alex is working on will be available within a day or two.
Thanks for the interest and suggestions guys!!
Taylor
|
|
|
09/29/2006 10:20:00
|
tgautier
seraphim
Joined: 06/05/2006 12:19:26
Messages: 1781
Offline
|
Alex Kozlenkov wrote:
...
Now one thing that happens and really puzzles me is that the bean still keeps its state after all applications using it are already finished.
...
Alex,
Let me address one issue at a time, this behavior is actually the way the product is supposed to behave.
When you make something shared in DSO, it does not go away when the application goes away.
I completely understand why this seems counterintuitive at first. Let me explain.
When you share an object using DSO it goes into the shared graph of objects. Those objects persist cluster wide - they are not specific to that application any longer. If the application fails on a single node, the objects are still available in the cluster. If the node/application is restarted, it attaches to the cluster and it sees the state in the cluster.
As a concrete example, consider this behavior in a web application, where the state is the user's session context. If the Application Server were to die, and come back, you would want the user's context to continue to persist.
I hope that helps to understand what is happening.
Taylor
|
|
|
|