What about using the Greenwich time with the existing timestamp? When there is a timezone critical solution, Greenwich time can be used as it is the same.
Anyway in practice I don't think timestamp is the best way to order the messages as it may have so many synchronization problems. Although it may not be a problem in millisecond range, clock drift can happen in highly moving servers due to time change according to relativity unless they have special clock synchronization mechanism. (e.g. Satellites) And it is not possible to order the messages passed during a single millisecond if the timestamp is in millisecond range as now. The only solution for the activity monitoring problem can be achieved by maintaining an message counter in the data agent. The counter should be incremented when each message is passed through the data agent and sent to the BAM. But there also we have a problem. Since data agents exists there in multiple threads the counter should be incremented as a atomic variable which is an expensive mechanism. *Maninda Edirisooriya* Software Engineer *WSO2, Inc. *lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *Phone* : +94 777603226 On Wed, Nov 6, 2013 at 7:58 AM, Srinath Perera <[email protected]> wrote: > Instead, can we let users decide which timezone to be used across all BAM > nodes? Problem is with timestamp + timezone, the time based queries get > complicated and expensive. I think indexes will not work anymore. > > --Srinath > > > On Tue, Nov 5, 2013 at 8:21 AM, Dunith Dhanushka <[email protected]> wrote: > >> Hi all, >> >> Currently BAM adds its current timestamp to the events that are being >> persisted to Cassandra. But there can be situations like data publishers >> and BAM instances are hosted in different timezones. >> For instance APIM and BAM can be hosted in two data ceneters of two >> different timezones. Events published from APIM will be stored in BAM with >> BAM's current timestamp. >> >> So it is impossible to tell from BAM side that at what time a particular >> event has occured in APIM. This means the time which event has been >> published from APIM, not the time that received by BAM. >> But if theres a way of BAM to save its timezone with events, that >> informtion(timezone + timestamp) can be used to derive the time that events >> had been published at APIM side. >> >> As a solution, in addition to timestamp we are going to store BAM's >> system timezone alongside with events. Required changes will happen in >> data-bridge componet. >> >> In fact, UTC offset of the system default timezone will be saved with >> each event (UTC offset is the offset in milliseconds for the given time >> zone to UTC, at the given time) so that it'd be easier for Hive queries to >> manipulate numeric values rather than timezone name strings. >> >> Your feedback is highly appreciated! >> >> Thanks, >> -- >> Regards, >> >> Dunith Dhanushka, >> Senior Software Engineer - BAM, >> WSO2 Inc, >> >> Mobile - +94 71 8615744 >> Blog - dunithd.wordpress.com <http://blog.dunith.com> >> Twitter - @dunithd <http://twitter.com/dunithd> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://people.apache.org/~hemapani/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
