Hi Anuja and Pamod,

On Fri, Jun 5, 2015 at 9:47 PM, Pamod Sylvester <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> 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
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Asitha Nanayakkara*
Software Engineer
WSO2, Inc. http://wso2.com/
Mob: + 94 77 85 30 682
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to