Migrating from PojoCache 1.3 to 1.4

[igsjboss]

We are in the process of migrating from JBossCache 1.3.2 SP3 to 1.4.0GA and one some of our classes appears to no longer work with the new version of JBossCache. Moving back to 1.3.x resolves the issue.

Specifically, calling the notify method of the following class results in an exception in 1.4.0GA but not in 1.3.x.

Any ideas?

Thanks,
Ilan

Exception
=======
ERROR SessionService sendRemoteNotification - Can not send message remotely

com.intersolved.xmlserver.global_services.synchronizator.SynchronizationException: Can not notify

at com.intersolved.xmlserver.global_services.synchronizator.SynchronizationMetaData.notify(SynchronizationMetaData.java:197)

at com.intersolved.xmlserver.global_services.synchronizator.RemoteSynchronizationStorage.notify(RemoteSynchronizationStorage.java:51)

at com.intersolved.xmlserver.global_services.session.SessionService.sendRemoteNotification(SessionService.java:586)

at com.intersolved.xmlserver.global_services.session.SessionService.resetTimeout(SessionService.java:550)

at com.intersolved.xmlserver.global_services.session.SessionService.changeConnection(SessionService.java:339)

at com.intersolved.xmlserver.global_services.convertor.PacketConvertorService$4.processOwnCommands(PacketConvertorService.java:216)

at com.intersolved.xmlserver.global_services.convertor.PacketConvertorService$4.run(PacketConvertorService.java:161)

at com.intersolved.xmlserver.global_services.convertor.PacketConvertorService$5.run(PacketConvertorService.java:310)

at java.lang.Thread.run(Thread.java:595)

Caused by: com.intersolved.cluster.jsync.SynchronizeException: Can not notify

at com.intersolved.cluster.jsync.components.NotificationTreeCacheAOP.notify(NotificationTreeCacheAOP.java:48)

at com.intersolved.cluster.jsync.components.Synchronizer.notify(Synchronizer.java:420)

at com.intersolved.xmlserver.global_services.synchronizator.SynchronizationMetaData.notify(SynchronizationMetaData.java:195)

... 8 more

Caused by: java.lang.RuntimeException: failure to marshal argument(s)

at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:152)

at org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4159)

at org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4113)

at org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4221)

at org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4242)

at com.intersolved.cluster.jsync.components.NotificationTreeCacheAOP.notify(NotificationTreeCacheAOP.java:45)

... 10 more

Caused by: java.lang.IllegalArgumentException: MethodCall does not have a valid method id. Was this method call created with MethodCallFactory?

at org.jboss.cache.marshall.TreeCacheMarshaller140.marshallObject(TreeCacheMarshaller140.java:223)

at org.jboss.cache.marshall.TreeCacheMarshaller140.objectToStream(TreeCacheMarshaller140.java:94)

at org.jboss.cache.marshall.VersionAwareMarshaller.objectToByteBuffer(VersionAwareMarshaller.java:133)

at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:145)

... 15 more


CLASS
=========

public class NotificationTreeCacheAOP extends org.jboss.cache.aop.TreeCacheAop {

public void _notify(Serializable transport) {

fireNotification(transport);

}



public void notify(Serializable transport) throws SynchronizeException {

try {

callRemoteMethods(getMembers(), "_notify", new Class[]{Serializable.class}, new Object[]{transport}, false, true, getSyncReplTimeout());

} catch (Exception exp) {

throw new SynchronizeException("Can not notify", exp);

}

}



void fireNotification(Serializable transport) {

// Pass notification to listeners.

}

}

[ben.wang]

You can check the Jira for more details. But since 1.4, we have switched to use ID based replication to optimize performance. As a result, callRemoteMethods can't be used without proper method id.

User is not supposed to call that directly anyway. We have cleaned up the interface in the upcoming 2.0.

Do you have an alternative?

-Ben

[brian.stansberry]

Ilan,

Try creating an instance of org.jgroups.blocks.MethodCall and passing it to this overloaded version of callRemoteMethods:

public List callRemoteMethods(List mbrs, MethodCall method_call,
 boolean synchronous, boolean exclude_self, long timeout)
throws Exception

I think that will take care of your issue; let me know if it doesn't. When you mentioned the problem you were having with 1.4.0.CR2 I did some stuff to allow this kind of thing to work, but it seems that if you use the version of callRemoteMethods that you're using it bypasses what I did.

As Ben said, callRemoteMethods() will be taken out of the client API in 2.0. It's possible something like it may be accessible as an extension point, but that's not guaranteed, or even likely.

[manik]

Yes, I would not recommend binding your code to callRemoteMethods(). The API is deprecated and will certainly disappear in 2.0.0.

Like Brian said, it may be made available as a part of a SPI interface for plugin authors, but even then using it as a generic RPC solution to call your own arbitrary methods will not be supported as it will only allow the remote invocation of a fixed set of methods.