[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Clustering Spring Events(Automatic Event firing)  XML
Forum Index -> Terracotta for Spring
Author Message
vijay

journeyman

Joined: 03/02/2007 06:07:24
Messages: 22
Offline

Hi All

Can this event clustering automatically fire the event across all client applications so that we can have the listener method executed accordingly on all applications automatically?
zeeiyer

consul

Joined: 05/24/2006 14:28:28
Messages: 493
Offline

Yes - If you have a bean which implements the ApplicationListener interface that is deployed into a context, every time an ApplicationEvent gets published to the ApplicationContext, that bean will be notified. Since with with TC application context events can be distributed (see <directory_where_terracotta_installed>\spring\samples\events for an example), you could have a method that executed on all nodes in response to an event. hope that helps - we can provide more detail if additional questions...

Cheers

Sreeni Iyer, Terracotta.
Not a member yet - Click here to join the Terracotta Community
vijay

journeyman

Joined: 03/02/2007 06:07:24
Messages: 22
Offline

Can we fire a distributed event from inside a rmi service?
Gordon

journeyman

Joined: 12/13/2006 00:38:30
Messages: 44
Offline

Hi Vijay,

Yes -- as long as that rmi service would call the ApplicationContext.publishEvent() method on the app context which Terracotta for Spring is clustering.

Regards,

Gordon
Sr. Systems Engineer
Terracotta, Inc.
vijay

journeyman

Joined: 03/02/2007 06:07:24
Messages: 22
Offline

Hi all,

Can we keep one tomcat instance from getting the lock to a particular method specifically, using tc-config? So that I can specify that the tomcat instance on which my service is being hosted, don't get the lock in any case?


My second query , I tried with write & concurrent lock. both are showing the same behaviour such as only one tomcat instance(the one started last) gets the lock? where as I expect (in some cases atleast) other instances should get the lock.

Any thoughts on this situation?
vijay

journeyman

Joined: 03/02/2007 06:07:24
Messages: 22
Offline

Hi all,

If I replace my RMI service to an http service then will it make any difference in the behaviour(mentioned in previous question)?
zeeiyer

consul

Joined: 05/24/2006 14:28:28
Messages: 493
Offline

If I replace my RMI service to an http service then will it make any difference in the behaviour(mentioned in previous question)? 

Whether RMI or HTTP service - as long as the services publish an event to the application-context, the event can be distributed across the participants in the cluster with Terracotta spring.

I can specify that the tomcat instance on which my service is being hosted, don't get the lock in any case?  

Sorry your use-case still isn't clear - perhaps you could publish some code snippets. I am conjecturing that all Tomcat instances are running the same application, but then one of them additionally hosts the RMI/HTTP service - so the node that runs the services publishes an event to the application context - and you would not like that specific node to respond to that published event, but would like other nodes to respond. Presumably you could write some simple logic in your bean itself - so that bean instantated on the node running the service does not react to the published event.


I tried with write & concurrent lock........... I expect (in some cases atleast) other instances should get the lock.  

For the duration of a given monitor, Write - implies a single writer and no other readers. Concurrent ~ "no-op" - so multiple writers and readers can access the same reference simultaneously. I take it that the method you describe finished exeucting on a given jvm - in that case the lock gets awarded to any other VM as needed - sorry just conjecturing - your tc-config.xml and a code snippet would help. (you can also turn on lock debugging in the tc-config.xml).



Sreeni Iyer, Terracotta.
Not a member yet - Click here to join the Terracotta Community
vijay

journeyman

Joined: 03/02/2007 06:07:24
Messages: 22
Offline

Hi all,

I have a server app. which has two different events in it. Both have an entry in the tc-config because I want each event to be distributed with a different application. The job of the server is to fire any one of the events at a time (using some application logic).

Clients are there to react to the respective events which they have in them.

My clientapp1 has only first event and has only this event's reference in its the tc-config.

My clientapp2 has only second event and has only this event's reference in its the tc-config.

Now when the server fires the first event then it gets fired on both clientapp1 & clientapp2 (through TC server). Now since the clientapp2 doesn't have the first event therefore its throwing a ClassNotFoundException.

Now is there a way to stop tc firing this first event on clientapp2 and vice-versa.

Any thoughts on this.
zeeiyer

consul

Joined: 05/24/2006 14:28:28
Messages: 493
Offline

when the server fires the first event then it gets fired on both clientapp1 & clientapp2 (through TC server). Now since the clientapp2 doesn't have the first event therefore its throwing a ClassNotFoundException. Now is there a way to stop tc firing this first event on clientapp2 and vice-versa. 


Hi Vijay - Think that you would want a different application-context for each app. Events (and beans) are distributed across a cluster within the scope of an application-context. i.e. something like :
Code:
 <application-contexts>
 <application-context>   
     ...........
    <paths><path>*/app1.xml</path></paths>
    ...........
    <distributed-event>com.mycompany.pkga.event1</distributed-event>
 </application-context>
 
 <application-context>   
     ...........
    <paths><path>*/app2.xml</path></paths>
    ...........
    <distributed-event>com.mycompany.pkga.event2</distributed-event>
 </application-context>
 </application-contexts>
 ......
 


Is there any reason why you want to use the same application context across clientapp1 and clientapp2?
Thx.

Sreeni Iyer, Terracotta.
Not a member yet - Click here to join the Terracotta Community
ekulesho

master

Joined: 12/04/2006 08:49:08
Messages: 57
Offline

vijay wrote:
Now when the server fires the first event then it gets fired on both clientapp1 & clientapp2 (through TC server). Now since the clientapp2 doesn't have the first event therefore its throwing a ClassNotFoundException. 
I think that the approach Iyer suggesting is the way to go. But to get better understanding what is going on, can you please post the stack trace for this ClassNotFoundException? Thanks.
[WWW]
vijay

journeyman

Joined: 03/02/2007 06:07:24
Messages: 22
Offline

Hi siyer,

Do u mean to say that the server app. tc-config will have two <application-context> and the client app. tc-config will have only one <application-context>.

In that case for every new client I need to have a new applicationContext file on the server side. How will it effect the performance of the server app.

I am thinking of having a master worker implementation on Spring beans using Terracotta clustering. So will this logic will have a good performance.

Any thoughts?
zeeiyer

consul

Joined: 05/24/2006 14:28:28
Messages: 493
Offline

Hi Vijay:

Side-note: We normally recommend that the best practice wrt config location is to leave the cumulative config on the server. On the client you pass a java option like -Dtc.config=<TerracottaServer>:<dso-port> - so when the client JVM starts up it will bootstrap with the tc-config retrieved from the server (you then don't need a config on the client). This way you can ensure that there is only 1 config across the cluster. Definitely the way to go atleast in stage and production environments.

Also, am not saying that every client needs to have its own application context (if that were the case, none of the clients would share beans/events with any other client) - since events are distributed within the scope of an application context.

Lets say you have N appservers. I understood (perhaps mistakenly) your requirement as some M of the N need to be notified when event 1 fires and some N-M need a notification when event 2 fires. Hence the suggestion to break it up into 2 application contexts if all N should not be sharing events.

If instead the only requirement is that the node that originated the event shouldn't respond to the event, then you could implement some simple flag within the Bean that implements the ApplicationListener interface so it does not react if it is on the same node that published the event.

Perhaps I can send you a private message and we can get on a call to discuss the use-case further, to remove any doubts.

Yeah Master Worker has quite a bit of adoption. You could use either the POJO version or the Spring Version - (please use the pojo data grid/router implementation, which is the latest reincarnation and features routing to multiple queues).

Thanks.

Sreeni Iyer, Terracotta.
Not a member yet - Click here to join the Terracotta Community
 
Forum Index -> Terracotta for Spring
Go to:   
Powered by JForum 2.1.7 © JForum Team