3 Replies Latest reply on Aug 7, 2006 1:25 PM by Manik Surtani

    Migrating from PojoCache 1.3 to 1.4

    igsjboss Newbie

      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?


      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


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

      public void _notify(Serializable 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.



        • 1. Re: Migrating from PojoCache 1.3 to 1.4
          Ben Wang Master

          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?


          • 2. Re: Migrating from PojoCache 1.3 to 1.4
            Brian Stansberry Master


            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.

            • 3. Re: Migrating from PojoCache 1.3 to 1.4
              Manik Surtani Master

              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.