Actually we should maintain the counter at the message interceptor (e.g.: BAM mediator). Every message passes through the interception point should increment the counter at the interceptor. The atomic integer problem comes as there can be multiple threads running in the same interception point. Then the counter value before the increment should be sent to the receiver end. Yes, either we should extend the receiver API or we should send the counter value as a correlation data field.
*Maninda Edirisooriya* Software Engineer *WSO2, Inc.*lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *Phone* : +94 777603226 On Fri, Nov 15, 2013 at 7:06 AM, Srinath Perera <[email protected]> wrote: > +1 to go with Greenwich time, or provide a option to turn it on when > needed. > > Counter would not work either as there can be some time between when event > is created and receiver received it. > > I think we need to live with time stamp. If time accuracy is critical > users should sync clocks of all machines with NTP. > > --Srinath > > > On Wed, Nov 13, 2013 at 5:30 PM, Maninda Edirisooriya <[email protected]>wrote: > >> 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 >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > Director, Research, WSO2 Inc. > Visiting Faculty, University of Moratuwa > Member, Apache Software Foundation > Research Scientist, Lanka Software Foundation > Blog: http://srinathsview.blogspot.com/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > > _______________________________________________ > 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
