Announcement

Collapse
No announcement yet.

[OXtender for Business Mobility] Problems with PUSH updates in a OX clustered setup

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • [OXtender for Business Mobility] Problems with PUSH updates in a OX clustered setup

    Hi all,
    I've installed the OXtender for Business Mobility in my OX cluster (OXSE 6.14 rev 8) and I've noticed a "strange" behaviour with PUSH updates.

    I've followed the official guide for setting up my cluster, which is composed by:
    - 1 frontend Apache
    - 2 OX backends
    - 1 Mysql database

    With this setup, I'm testing the OXtender for Business Mobility using an iPhone with PUSH notifications.
    In order to test PUSH updates, I've logged in OX using the same user account with both the iPhone and the web client and then I've created a test appointment.

    Now my "problem":
    • when the browser and my iPhone connect to the same OX node (say ox1), if I create/move the test appointment within the browser I can see this change in my iPhone nearly in real time
    • when the browser and my iPhone connect to the different OX nodes (say ox1 for browser and ox2 for iPhone), if I create/move the test appointment within the browser I cannot see this change in my iPhone until I force a manual refresh


    Is this behaviour correct or am I missing some important cluster setting?

  • #2
    Hi,

    it seems that the object caches on server side are not talking to each other properly. You might check the cache.ccf configuration for the groupware.

    Greetings

    Comment


    • #3
      Thanks Martin
      I'm not 100% sure that my cluster setup is working correctly, I've followed the guide but some details are not clear to me.

      Here is my setup:
      • frontend Apache (sc-ccm04)
      • OX backends (sc-ccm02 and sc-ccm06)
      • Mysql database (sc-ccm05)



      The OXtender is configured for use the frontend Apache (sc-ccm04):
      Code:
      [root@sc-ccm02 ~]# vi /opt/open-xchange/etc/groupware/usm.properties
      
      ...
      com.openexchange.usm.ox.url=http://sc-ccm04.csi.it/ajax/

      I've setup a multicast address on both OX nodes (sc-ccm02 and sc-ccm06):
      Code:
      [root@sc-ccm02 ~]# route -n
      
      Kernel IP routing table
      Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
      10.102.250.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
      169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
      224.0.0.0       0.0.0.0         240.0.0.0       U     0      0        0 eth0
      0.0.0.0         10.102.250.1    0.0.0.0         UG    0      0        0 eth0
      This seems to work properly, because I can see some connections between OX nodes:
      Code:
      [root@sc-ccm02 ~]# netstat -tlpa | grep java | grep ESTABLISHED
      
      tcp        0      0 localhost.localdomain:57462 localhost.localdomain:38883 ESTABLISHED 26611/java
      tcp        0      0 localhost.localdomain:57461 localhost.localdomain:38884 ESTABLISHED 26524/java
      tcp        0      0 sc-ccm02.csi.it:57461       sc-ccm02.csi.it:38885       ESTABLISHED 26524/java
      tcp        0      0 localhost.localdomain:58849 localhost.localdomain:38892 ESTABLISHED 26611/java
      tcp        0      0 localhost.localdomain:57462 localhost.localdomain:38895 ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:57462       sc-ccm02.csi.it:38896       ESTABLISHED 26611/java
      tcp        0      0 localhost.localdomain:57461 localhost.localdomain:38864 ESTABLISHED 26524/java
      tcp        0      0 sc-ccm02.csi.it:38899       sc-ccm06.csi.it:58849       ESTABLISHED 26611/java
      tcp        0      0 localhost.localdomain:38892 localhost.localdomain:58849 ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:38893       sc-ccm05.csi.it:mysql       ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:38894       sc-ccm05.csi.it:mysql       ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:38891       sc-ccm05.csi.it:mysql       ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:58849       ::ffff:10.102.250.29:52308  ESTABLISHED 26611/java
      tcp        0      0 localhost.localdomain:38883 localhost.localdomain:57462 ESTABLISHED 26611/java
      tcp        0      0 localhost.localdomain:38895 localhost.localdomain:57462 ESTABLISHED 26524/java
      tcp        0      0 sc-ccm02.csi.it:38896       sc-ccm02.csi.it:57462       ESTABLISHED 26524/java
      tcp        0      0 localhost.localdomain:38864 localhost.localdomain:57461 ESTABLISHED 26524/java
      tcp        0      0 localhost.localdomain:38884 localhost.localdomain:57461 ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:38885       sc-ccm02.csi.it:57461       ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:38862       sc-ccm06.csi.it:57461       ESTABLISHED 26524/java
      tcp        0      0 sc-ccm02.csi.it:38882       sc-ccm06.csi.it:57461       ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:38898       sc-ccm06.csi.it:57462       ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:38897       sc-ccm06.csi.it:57462       ESTABLISHED 26524/java
      tcp        0      0 sc-ccm02.csi.it:57462       sc-ccm06.csi.it:38668       ESTABLISHED 26611/java
      tcp        0      0 sc-ccm02.csi.it:57461       sc-ccm06.csi.it:38669       ESTABLISHED 26524/java
      tcp        0      0 sc-ccm02.csi.it:58849       sc-ccm06.csi.it:38677       ESTABLISHED 26611/java

      As regards JCS files, it's not clear to me what changes are needed for cluster setup so, at the moment, I've not touched them:
      Code:
      [root@sc-ccm02 ~]# vi /opt/open-xchange/etc/admindaemon/cache.ccf
      
      jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
      jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
      # jcs.auxiliary.LTCP.attributes.TcpServers=127.0.0.1:57462
      jcs.auxiliary.LTCP.attributes.TcpListenerPort=57461
      jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=224.0.0.1
      jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6780
      jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true
      jcs.auxiliary.LTCP.attributes.Receive=true
      jcs.auxiliary.LTCP.attributes.AllowGet=false
      jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=true
      jcs.auxiliary.LTCP.attributes.FilterRemoveByHashCode=false
      Code:
      [root@sc-ccm02 ~]# vi /opt/open-xchange/etc/groupware/cache.ccf
      
      jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
      jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
      # jcs.auxiliary.LTCP.attributes.TcpServers=127.0.0.1:57461
      jcs.auxiliary.LTCP.attributes.TcpListenerPort=57462
      jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=224.0.0.1
      jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6780
      jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true
      jcs.auxiliary.LTCP.attributes.Receive=true
      jcs.auxiliary.LTCP.attributes.AllowGet=false
      jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=true
      jcs.auxiliary.LTCP.attributes.FilterRemoveByHashCode=false
      Code:
      [root@sc-ccm02 ~]# vi /opt/open-xchange/etc/groupware/sessioncache.ccf
      
      jcs.auxiliary.SessionLTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
      jcs.auxiliary.SessionLTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
      # jcs.auxiliary.SessionLTCP.attributes.TcpServers=<host or ip>:58849
      jcs.auxiliary.SessionLTCP.attributes.TcpListenerPort=58849
      jcs.auxiliary.SessionLTCP.attributes.UdpDiscoveryAddr=224.0.0.1
      jcs.auxiliary.SessionLTCP.attributes.UdpDiscoveryPort=6781
      jcs.auxiliary.SessionLTCP.attributes.UdpDiscoveryEnabled=true
      jcs.auxiliary.SessionLTCP.attributes.Receive=true
      jcs.auxiliary.SessionLTCP.attributes.AllowGet=false
      jcs.auxiliary.SessionLTCP.attributes.IssueRemoveOnPut=false
      jcs.auxiliary.SessionLTCP.attributes.FilterRemoveByHashCode=false

      Is my configuration correct?

      Thanks for your precious support

      Comment


      • #4
        I've also noticed that open-xchange-admin.log is full of LateralTCPSender exceptions...

        Code:
        Feb 9, 2010 9:27:51 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService <init>
        SEVERE: Could not create sender to [127.0.0.1:57462] -- Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:27:51 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager <init>
        SEVERE: Failure, lateral instance will use zombie service
        java.io.IOException: Socket is null, cannot connect to 127.0.0.1:57462
                at org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender.init(LateralTCPSender.java:141)
                at org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender.<init>(LateralTCPSender.java:111)
                at org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService.<init>(LateralTCPService.java:72)
                at org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager.<init>(LateralTCPCacheManager.java:167)
                at org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager.getInstance(LateralTCPCacheManager.java:108)
                at org.apache.jcs.auxiliary.lateral.socket.tcp.discovery.UDPDiscoveryReceiver$MessageHandler.run(UDPDiscoveryReceiver.java:324)
                at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
                at java.lang.Thread.run(Thread.java:595)
        
        ...
        
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService <init>
        SEVERE: Could not create sender to [127.0.0.1:57462] -- Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager fixService
        SEVERE: Can't fix Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.LateralCacheRestore canFix
        SEVERE: Can't fix Can't fix Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService <init>
        SEVERE: Could not create sender to [127.0.0.1:57462] -- Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager fixService
        SEVERE: Can't fix Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.LateralCacheRestore canFix
        SEVERE: Can't fix Can't fix Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService <init>
        SEVERE: Could not create sender to [127.0.0.1:57462] -- Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager fixService
        SEVERE: Can't fix Socket is null, cannot connect to 127.0.0.1:57462
        Feb 9, 2010 9:28:11 AM org.apache.jcs.auxiliary.lateral.LateralCacheRestore canFix
        SEVERE: Can't fix Can't fix Socket is null, cannot connect to 127.0.0.1:57462
        
        ...

        Comment


        • #5
          The admindaemon is typically not responsible for mobile synchronization. If you're running just two servers, you could work with static values instead of using multicast networking.
          jcs.auxiliary.LTCP.attributes.TcpServers=127.0.0.1 :57462, other.host:57462
          jcs.auxiliary.LTCP.attributes.TcpListenerPort=5746 1
          jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled= false

          You might also want to contact our support or professional services when setting up and rolling out an HA environment.

          Greetings
          Last edited by Martin Heiland; 02-09-2010, 02:05 PM.

          Comment


          • #6
            Well, I've tried to tweak jcs settings using manual values instead of multicast autodiscovery.
            For example, for admin daemon cache:
            Code:
            [root@sc-ccm02 ~]# vi /opt/open-xchange/etc/admindaemon/cache.ccf
            
            jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
            jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
            jcs.auxiliary.LTCP.attributes.TcpServers=127.0.0.1:57461,10.102.250.207:57461
            jcs.auxiliary.LTCP.attributes.TcpListenerPort=57461
            jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
            Is this correct? Should I set TcpServers with both localhost and the other OX server, using the same port as TcpListenerPort?
            Using a different TcpServers port (eg: 57462, as in your example) seems not to work, because this port should be used by the groupware daemon cache, but I'm not 100% sure!


            With those settings, now my open-xchange-admin.log does no longer report so many LateralTCPSender exceptions (as long as both admin daemons are up and running of course!)...

            But my original "problem" is still here (of course, changing admin daemon settings does not influence mobile synchronization). If my iPhone and the browser connects to 2 different nodes, I cannot see changes made through the browser as long as I force an update in iPhone UI (eg: close and re-open the Calendar client).
            This is not a big problem, but I would like to know if this is a technical limitation (for example, because a java Listener cannot be notified if the source of changes is in another JVM) or if I'm missing some important cluster configuration...

            Thanks for your support

            Comment

            Working...
            X