We have been looking at the code and wondered if CLOCK_MONOTONIC can be used. Qpid uses AbsTime everywhere. Now it is possible that Qpid has decided to use REALTIME because there is the need for a real time clock between machines running Qpid; there might be timers in the client & the daemon that depend on using the same time reference.
Any thoughts? Nitin -----Original Message----- From: Nitin Shah [mailto:[email protected]] Sent: Wednesday, March 26, 2014 10:56 AM To: Andrew Stitcher; [email protected] Cc: Gordon Sim ([email protected]); Atif Faheem; Tony Hart; Lynne Morrison Subject: RE: Qpid and Behavior on NTP time change Hi Andrew and Qpid team, We are really blocked by this issue and need to have a conversation going about the options to resolve our issue. I am adding others from our team so they can chime in if necessary. Thanks Nitin -----Original Message----- From: Nitin Shah Sent: Tuesday, March 25, 2014 4:44 PM To: Andrew Stitcher; [email protected] Cc: Gordon Sim ([email protected]); Nitin Shah Subject: RE: Qpid and Behavior on NTP time change Andrew, We have the NTP running on all the cards and I think I misled you on that. However, we have a CLI that allows the user to set the time and date and that is propagated across all cards via qpid messaging. First the module that has the qpid broker running updates the clock locally and that seems to cause the lock up. If NTP does it , that seems fine. Nitin -----Original Message----- From: Andrew Stitcher [mailto:[email protected]] Sent: Tuesday, March 25, 2014 4:26 PM To: [email protected] Cc: Nitin Shah; Gordon Sim ([email protected]) Subject: Re: Qpid and Behavior on NTP time change On Tue, 2014-03-25 at 14:55 -0400, Nitin Shah wrote: > Hi , > > I have talked to this mailing list before as we are users of QPID in our > distributed system. Our architecture has multiple modules connected together > via a backplane Ethernet link. We use QPID version 0.24 release both broker > and clients are C++. > > Recently we have been trying to synchronize time across all modules using > the messaging mechanism. However, we are seeing the following problem and the > sequence of operation is this: > > > 1. The module running the Qpid Broker receives an time update from a > NTP server. It updates the local date/time and hwclock ( we are on Linux ) > and sends a message that suggests all the other modules to update their > clocks accordingly using the messaging in Qpid. > > 2. These messages are not getting sent or are not getting delivered to > the other modules until we kill and restart the broker. It seems this must be > as a result of the time change that has happened where the broker is running. > THERE IS A SHIFT IN THE TIME BASE. > > Can someone explain what is going on with this? > > Any guidance and may be suggestions will be welcome. We would like to > understand what is happening internally and see if we are doing something > wrong. Qpid like many other programs will get confused if the time ever goes backwards whilst it is running. I think that there should not be a problem if NTP only adjusts the time forwards. AFAIR ntp dameons always used to be arranged so that they adjusted the clock without ever setting the time backwards. Because it has been known for many years that many parts of Unix/Linux cannot cope with time going backwards. Incidentally why are you using AMQP to send NTP messages about when NTP is well adapted for the task itself? Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
