DIstributor service Failing to Log

Topics: Logging Application Block
May 20, 2010 at 8:28 AM

Hi all,

I am experiencing proplem with the distributor service . I have configured the MSMQ (messaging queue) where i write my log files & in the MSMQDistriibutor.exe.config file i have configured

the tracelistener (Rolling Flat File Trace Listener) in the File name property of the trace listener i have configured the path for my log file on local system .Now if i deny the permission on the folder to write log

What i Suppose is Distributor service Should not write the log & log files should be maintained in the queue!! (there is a deny permission on the folder where i want to write the log).

but the above mentioned thing is not happening infact the logs are moved from the Message queue & i dont know where r they going (since acc to my Trace listener it should go to local filesys configure but since it doesnt have permission to write )

where can it go & My distributor service is also going for a Toss in this case as it doesnt support any further logging & i have to restart the service & remove the permission on the logging folder to continue in the normal way in which it logs perfectly.

Can any body pls explain this behaviour

and if the DIstributor service or any other service is failing how can i get to know since it is not there in windows event logs  or where i can search ??

How to correct this behaviour??

 

 

 

 

 

May 20, 2010 at 8:41 AM
Edited May 20, 2010 at 8:42 AM

Actually, what happens is that the item in the queue wasn't logged since there is no permission to write on the folder.  The message was removed from the queue though because the code does not check if the logging was successful or not.  Unfortunately, you cannot correct this behavior without modifying the source code.  The relevant code would be the ReceiveQueuedMessages method of the MsmqLogDistributor class.

if (logEntry != null)
{
         logWriter.Write(logEntry);
}

message = msmq.Receive();

As you know, the Receive method automatically removes the item from the queue.  You must have a way of knowing if the logging process was successful or not because the LAB doesn't propagate the exceptions which occurred while processing log entries.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

May 20, 2010 at 10:37 AM

I didn’t get what  u mean to say Sarah 

Since I am writing all my logs to Message queue asynchronously & I have not used any MSMQLogDIstributor Class in my relevant code it is all the part of entlib which i am using

I usually write the log as 

            LogEntry log = new LogEntry();

           

            log.ExtendedProperties.Add("AssemblyName", assemblyName);

            log.ExtendedProperties.Add("ClassName", className);

log.Categories.Add(categoryName);

log.Message = logMessage;

 

try

            {

                Logger.Write(log);

            }

            catch

            {

 // catching the exception here & writing to event logs

}

 

Pls let me know if i am wrong here

 

 

           

Please let me know in case any changes reqd. & how can I implement the same .

 

Thanks a lot in advance

Rajesh

May 21, 2010 at 12:09 AM

I was referring to the source code of the distributor service and the MsmqLogDistributor is part of it.  It's in the Logging.MsmqLogDistributor project.  You can't fix it without modifying it and the relevant code which causes this is the one I posted above which is from the MsmqLogDistributor.ReceiveQueuedMessages() method.   That method does the retrieving of the message from the queue and logging it.  What happens is that, it calls logWriter.Write(logEntry) and then calls msmq.Receive().  In your case, when you deny permissions to write to the folder, the call to logWriter.Write(logEntry) didnt' throw an exception (although the logging failed ) because it is designed to swallow the exceptions if any of the trace listeners failed to log.  The msmq.Receive() was then executed causing the message from the queue to be deleted.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com