Replication doesn't work even with the sample code provided

[mitra123]

Hi,
I am having this problem and I am almost certain it is the environment which we currently are testing JBOSSCache but the issue is that we are not able to replicate the data from cache1 to cahce2.

I have even reverted back into using the sample code that is included in the download (studentMainTest.java)

Updating the data in cache1 is not replicated to cache2.

The initial data is replicated when the 2 cache are created but after that any changes made in cache 1 doesn't get replicated to cache2.

Could you please point me in the right direction to fix this problem.

[manik]

Does JGroups work in the first place?

See:

http://www.jgroups.org/javagroupsnew/docs/newuser/node6.html

and

http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups

[mitra123]

Hi,
jgroups.jar is by default included in the \lib of jbosscache download and it is included in the class path of the project I am running.

Is this enough?

[malek256]

We note that replication occurs if you remove and then perform a putObject, but not otherwise

That is, the following pseudo-code illustrates a pattern which returns the modified data

MyObject myObject = new MyObject();
myObject.SetValue("0");

cache1_.putObject("/key/", myObject);
myObject = cache1_.getObject("/key/");
myObject.SetValue("1");

myObject2 = cache2_.getObject("/key/");
// myObject2.GetValue returns 0

cache1_.remove("/key/");
cache1_.putObject("/key/", myObject);

myObject2 = cache2_.getObject("/key/");
// myObject2.GetValue returns 1

[brian.stansberry]

Has the MyObject class been instrumented (aka aspectized) for use in PojoCache?

[malek256]

I can check - but can you explain why that would allow for communication after a remove/put and when the cache is created but not when it is altered?

Does the aspectizing insert hooks within the get/sets for triggers? I apologize for asking what's probably an obvious question - I am learning as we proceed.

[brian.stansberry]

Yes, aspectizing is what makes it possible for the cache to detect changes in the object. (It actually detects changes in internal fields rather than getter/setter invocations.) Without this the cache has no idea the object has changed and needs to be replicated, unless you call putObject() again.

In your pseudo-code, the remove() call should be unnecessary. The second call to putObject should have been enough to cause the data to replicate.

See http://www.onjava.com/pub/a/onjava/2005/11/09/jboss-pojo-cache.html for a general discussion of PojoCache vs. plain TreeCache.

[malek256]

Thanks for the explanation - I do see the content within the jboss-aop.xml file, so this should be functional.

'myObject' is a contrived example for illustration - in fact, we are using code based upon the sample PojoCache which uses the Student, Person, Course, etc.

Without the remove(), the replication does not occur. It must have a remove then a putObject.

[brian.stansberry]

Having a jboss-aop.xml file isn't enough; you have to aspectize your classes. The readme.txt files in the examples discuss how to do this.

I'll bug Ben Wang about the need to call removeObject() before a second putObject() if you haven't aspectized the class -- shouldn't be that way.

[malek256]

Yes, it is aspectized - but not really :)

The missing piece of the puzzle's looks to be located. Running the files via run.aop.example is functional.

We are running this within Eclipse. There it is only semi-functional.

We aspectized that source externally and are only referencing it's classes but I hypothesize the configuration is such that eclipse detects the .class change done outside of its control and is overwriting the aspectized class.

[sambitd]

Hi,
Im getting the same problem here while trying to replicate pojo cache. It expects remove method to be called before putObject for replication to work properly. I'm wondering if it is mandatory to use remove method before putObject always. Using this approach we have encountered a trivial issue some thing as below. Lets say there are 2 threads running in two cache nodes. One thread is updating the cache while the other is reading the cache. Since the first thread calls remove method before putting objects into cache, at times the second thread gets null object for the same key. Do we need to handle this using transaction of jboss cache automatically handles it by any configuration.