Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-4427

Magnolia cannot sync when author and public servers are separate and in separate time zones, because of timestamp check in Receive Filter



    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Not an issue
    • Affects Version/s: 4.5.2
    • Fix Version/s: None
    • Component/s: activation
    • Labels:
    • Environment:
      Linux/Tomcat6 in both local author and remote public instance


      I've looked for at least 6 hours and trolled every google search I can think of to find an answer to this and have considered downloading the code just to comment this out because your system does a timestamp check in ReceiveFilter (info.magnolia.module.exchangesimple.ReceiveFilter) and this timestamp check fails for us because our internal author and production public server are in separate time zones. I'm can't imagine that this is not possible to have this deployed that way correct? If So what mechanism exists for setting up the tolerance, if none then this would seem to be a bug. I have an existing instance running like this but from a prior version of Magnolia (4.2) and it does not apparently do this timestamp check because it doesn't fail like this so it must have been added since 4.2? The exception is thrown on line 309 by the way (or it appears from the subversion browse I did)

      The actual error code, embedded in the software indicates that the server times MUST be synced or the tolerance set high enough to counter the difference but from what I can see after extensive digging is that there is no place to set this "tolerance" value and I can't sync the times on the servers because they're in different time zones.

      If There is a cure for this (a place or method to set this tolerance) please, this is absolutely stopping us dead in the water but I can find no references to how to overcome this anywhere in your system.




            mdivilek Milan Divilek
            stranm Mike Stran
            0 Vote for this issue
            0 Start watching this issue


              Date of First Response: