Hi, Here is the progress so far.
According to the last discussion, I stored the flow in the message context and persist that when the flow is finished. And also I have created a separate thread to persist the data asynchronously to the database. To identify each mediator, I have added an id for each mediator. I am using two tables, one for store the message flow and other one to store the mediator details. When building the message flow, I am using a separate data structure in which one node maps to another node set. In that way, I can store the message flows when the message is cloning, iterating and etc. I have explained the data structure using an example in [1]. And the current implementations are in the repository [2] and [3]. [1]. https://docs.google.com/document/d/1k0vrAbzQZyD7PDSHyKntEmqoflyH-iSjC_eo9gAxdoM/edit?usp=sharing [2]. https://github.com/ChanakaCooray/carbon-mediation/tree/MessageFlowTrace [3]. https://github.com/ChanakaCooray/wso2-synapse/tree/MessageFlowTrace Thanks, On Thu, Jun 18, 2015 at 10:11 PM, Isuru Udana <[email protected]> wrote: > Hi Cryril, > > Thanks for the idea. > > Message context is the entity which flows through the mediation flow (both > request/response path). We thought of saving trace details in the message > context itself will ease the correlation. However we cannot save all the > information in the message context, as it will increase the memory usage. > Information like message payload, property values can be written to the db > in an asynchronous manner (not blocking the mediation flow) and we can keep > a reference to those db entries in the message context. > > We need to decide on a suitable data structure (probably a stack) which > can hold these information. > > When we have flow branching mediators like Filter, Clone, we may need a > parent message id to correlate as well. > > Now the challenge is to decide a suitable data structure to hold these > trace information in the message context. > > Thanks. > > > > On Thu, Jun 18, 2015 at 1:54 PM, Cyril Rognon <[email protected]> wrote: > >> Hi, >> >> would it be too expensive or difficult to have a parent Message id if the >> original Message id is to be changed ? This would allow us to correlate >> flows later. >> >> thanks, >> Cyril >> >> On Wed, Jun 10, 2015 at 1:26 PM, Chanaka Sampath Cooray < >> [email protected]> wrote: >> >>> Hi, >>> >>> Here are the points we have discussed in the last meeting. >>> >>> - Building a proper data structure to store and process the Message >>> Flow >>> - Persist the collected data after the Message Flow has completely >>> finished - Store the data from the data collection points in memory until >>> the message flow finished >>> - Store the first generated Message Id as a property in the Message >>> Context - message id will be changed in some situations, so we can't be >>> able to track the message flow >>> - Pay special attention to the mediators extends >>> from FlowContinuableMediator - Mediators those have branches >>> - Store the timestamp, payload, headers and property set as the >>> basic information >>> >>> Thanks, >>> >>> On Tue, Jun 9, 2015 at 4:20 PM, Isuru Udana <[email protected]> wrote: >>> >>>> Hi Chanaka, >>>> >>>> Can you please update the thread with notes of the meeting we had >>>> yesterday ? >>>> >>>> On Tue, Jun 2, 2015 at 3:39 PM, Chanaka Sampath Cooray < >>>> [email protected]> wrote: >>>> >>>>> Hi Manuranga, >>>>> >>>>> Yes, the data publishing mostly goes through the same log4j flow. But >>>>> we decided to write the data to the database in our initial discussion. >>>>> But >>>>> it is not confirmed yet. >>>>> >>>>> Thanks, >>>>> >>>>> On Tue, Jun 2, 2015 at 3:27 PM, Manuranga Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> Does this data publishing goes through the same log4j flow? Is the >>>>>> data collector written as a log4j appender ? >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Chanaka Sampath Cooray* >>>>> Undergraduate | Department of Computer Science and >>>>> Engineering,University of Moratuwa >>>>> Mobile: +94 71 361 4884 >>>>> E-Mail: [email protected] >>>>> Linked-In: https://lk.linkedin.com/pub/chanaka-sampath/65/221/102 >>>>> <https://lk.linkedin.com/pub/chanaka-sampath/65/221/102> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Isuru Udana* >>>> Associate Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> email: [email protected] cell: +94 77 3791887 >>>> blog: http://mytecheye.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> *Chanaka Sampath Cooray* >>> Undergraduate | Department of Computer Science and >>> Engineering,University of Moratuwa >>> Mobile: +94 71 361 4884 >>> E-Mail: [email protected] >>> Linked-In: https://lk.linkedin.com/pub/chanaka-sampath/65/221/102 >>> <https://lk.linkedin.com/pub/chanaka-sampath/65/221/102> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > > -- > *Isuru Udana* > Associate Technical Lead > WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 3791887 > blog: http://mytecheye.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Chanaka Sampath Cooray* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Mobile: +94 71 361 4884 E-Mail: [email protected] Linked-In: https://lk.linkedin.com/pub/chanaka-sampath/65/221/102 <https://lk.linkedin.com/pub/chanaka-sampath/65/221/102>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
