Hi,
I have re-organized logs of WSO2 Message Broker. Following are the facts:
1. Per message logs are now "trace" level logs.
2. Debug logs will be mainly subscription related logs and how many
messages received/sent and qpid debug logs etc.
3. Whole trace logs from different classes of the server can be enable by
following single entry.
#trace level logs for WSO2 Message Broker
#log4j.logger.org.wso2.andes.server.trace=TRACE,CARBON_TRACE_LOGFILE
This entry is kept commented out by default.
4. Trace logs are directed to CARBON_TRACE_LOGFILE by default. This can be
changed by log4j.properties file.
5. Also added following logs for troubleshooting.
#andes logs for troubleshooting
#log4j.logger.org.wso2.andes.server.cassandra.QueueDeliveryWorker=DEBUG
#log4j.logger.org.wso2.andes.server.cassandra.TopicDeliveryWorker=DEBUG
#log4j.logger.org.wso2.andes.server.cassandra.GlobalQueueWorker=DEBUG
#log4j.logger.org.wso2.andes.server.cassandra.OnflightMessageTracker=DEBUG
#log4j.logger.org.wso2.andes.server.cassandra.DefaultClusteringEnabledSubscriptionManager=DEBUG
#log4j.logger.org.wso2.andes.server.store.CassandraMessageStore=DEBUG
#log4j.logger.org.wso2.andes.server.exchange.TopicExchange=DEBUG
#log4j.logger.org.wso2.andes.server.AMQChannel=DEBUG
Maybe we need to add these configurations to docs?
On Sun, Mar 23, 2014 at 7:33 AM, Srinath Perera <[email protected]> wrote:
> +1
>
>
> On Sun, Mar 23, 2014 at 7:16 AM, Shammi Jayasinghe <[email protected]>wrote:
>
>> Hi Hasitha,
>>
>> Yes, we need to go for a separate log appender as in ESB to trace message
>> level logs since if we use the default log appender , we ll have to go
>> class by class for required classes and enable debug logs. With this , we
>> ll not need to do that.
>>
>> +1 for this approach.
>>
>> Thanks
>> Shammi
>>
>>
>> On Sat, Mar 22, 2014 at 7:40 AM, Hasitha Hiranya <[email protected]>wrote:
>>
>>> Hi,
>>>
>>> Intended to do the $subject.
>>>
>>> We have a lot of debug logs. Some are per message.
>>> When troubleshooting an issue this is almost the only way to identify
>>> the problems (race conditions - threading issues etc).
>>>
>>> We intend to separate out the debug logs in our control (cannot help
>>> qpid internals) as below
>>>
>>> 1. Non per-message logs : subscription information logs/how many
>>> messages were read/how many messages were moved etc etc
>>>
>>> 2. Per message logs: add as "Trace" level logs with a separate appender
>>> like in ESB.
>>>
>>> >>Message with id x came to the sever
>>> >>Message x metadata were written
>>> >>Message x content chunk y is written
>>> >>Message x was cut from Global Queue a to node queue b
>>> >>Message x was read from Node queue b
>>> >>Message with id x was sent to the subscriber s1
>>> >>Message with id x was sent to the subscriber s2
>>> >>Message with id x was acked sy subscriber s1
>>> >>Message with id x waas acked by subscriber s2
>>> >>Message with id x is considered delivered and removed from store.
>>> >>Content belonging to message x was removed from store
>>>
>>> Is this the correct approach? WDYT?
>>>
>>> Thanks.
>>>
>>> --
>>> *Hasitha Abeykoon*
>>> Software Engineer; WSO2, Inc.; http://wso2.com
>>> *cell:* *+94 719363063*
>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
>>>
>>>
>>
>>
>> --
>> Best Regards,
>>
>> * Shammi Jayasinghe*
>> Associate Tech Lead
>> WSO2, Inc.; http://wso2.com,
>> mobile: +94 71 4493085
>>
>>
>
>
> --
> ============================
> 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
>
--
*Hasitha Abeykoon*
Software Engineer; WSO2, Inc.; http://wso2.com
*cell:* *+94 719363063*
*blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
