Hi Pamod and Asitha, Thanks for the ideas. I think implementing a separate class for message tracing would be nice to have.
I'm not clean on mapping internal and external message ids. Can you please explain more on that? Thanks, Anuja. On Fri, Jun 5, 2015 at 10:16 PM, Asitha Nanayakkara <asi...@wso2.com> wrote: > Hi Anuja and Pamod, > > On Fri, Jun 5, 2015 at 9:47 PM, Pamod Sylvester <pa...@wso2.com> wrote: > >> Hi Anuja, >> >> Some of the information i could think of, >> >> 1) JMS levels header information i.e arrival time stamps >> 2) Message content itself ? (in this case we might need to think about >> the message sizes as well tracing large messages etc might lead into >> several issues, format i.e whether its binary/plain text) >> > > What if we use a seperate class to log message content. In that way if we > need to log message content we can enable logs of that class. There might > be an instance we need to log a huge message as well. > May be this is a wacky solution. But we can have the option to log or not > to log content with this option. > > 3) Also for AMQP the frame information (frame number) >> 4) For MQTT we could include (QoS level, retain status, whether this >> message is a retry (duplication flag)) >> >> Also, for each message we might need a way to distinguish the trace >> message ? maybe from the id ? so that we could track the state of it at >> different layers (i.e Message inbound handlers, slot delivery worker, >> message flusher, delivery handlers) >> >> Thanks, >> Pamod >> > > In addition we can log the current state of the message. To trace a message > > - Reached Protocol level > - Reached Andes Core > - Published to Disruptor > - Pre processed message > - Written to DB > - Slot information updated > > Other than that to complete the whole story we can add trace logs for > delivery path as well. > > - Message metadata read from DB > - Message metadata buffered for delivery to subscriber > - Message metadata put in to Delivery Disruptor > - Message content read > - Message dispatched to protocol level for delivery > - Message is sent from protocol level to subscriber > > For these logs we can have the internal message Id after message pre > processor. we might not need to log the whole message. But there should be > a trace log to map the internal message id to the actual message at some > point. > > In addition it would be nice if we can have a separate class to log the > whole message throughout its journey through MB. Since its done with a > separate class we can enable them or disable them without any effect to the > trace logs. Trace logging should be done with adiquate information to trace > a message through ESB IMO. > > Thanks, > Asitha > > >> On Fri, Jun 5, 2015 at 10:52 AM, Anuja Herath <an...@wso2.com> wrote: >> >>> Hi, >>> >>> Related to Jira [1], we need to add a trace level log when every time a >>> message is received. What information of the received message can be useful >>> to include in the log message? >>> >>> [1] https://wso2.org/jira/browse/MB-803 >>> >>> -- >>> Anuja Herath >>> *Software Engineer* >>> *WSO2, Inc.* >>> Mobile : +94 (0)71 429 8861 >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Pamod Sylvester * >> >> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >> cell: +94 77 7779495 >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Asitha Nanayakkara* > Software Engineer > WSO2, Inc. http://wso2.com/ > Mob: + 94 77 85 30 682 > > -- Anuja Herath *Software Engineer* *WSO2, Inc.* Mobile : +94 (0)71 429 8861
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
