我在我的UAT
环境中遇到了一个非常奇怪的问题。我有两个WCF
相互通信的服务。在较高的层次上,我的 Web 应用程序与业务层通信,并从那里将 wcf 请求传递到处理所有请求并返回响应的事务层。我面临的问题是事务层接收业务层发送的请求大约需要 1 分钟。服务部署在WCF
同一台服务器上,并且此应用程序设置在生产中完美运行,所以我不确定发生了什么......
示例:
Web-frontend 向业务层发送 wcf 请求以获取所有广告的列表。业务层执行一些安全检查(我已从示例中删除),然后通过另一个 WCF 请求将请求简单地传递到事务层。但是事务层接收这个请求需要 1 分钟。
业务层:
public partial class AdsManagementService : IAdsManagementService
{
public ListAdvertisementResponse ListAdvertisement(ListAdvertisementRequest request)
{
LogManager.Write("Initiated AdsManagement.AdsManagentService.ListAdvertisement()", LogCategory.Trace.ToString());
var response = new ListAdvertisementResponse();
response.Advertisements = new List<Advertisement>();
LogManager.Write("Authentication token validated in AdsManagement.AdsManagentService.ListAdvertisement()", LogCategory.Event.ToString());
var client = new AdService.AdsManagementServiceClient();
try
{
response = client.ListAdvertisement(request);
LogManager.Write("response received by AdsManagement.AdsManagentService.ListAdvertisement()", LogCategory.Event.ToString());
}
finally
{
try
{
client.Close();
}
catch (Exception ex)
{
LogManager.ExceptionHandler(ex);
}
}
}
}
交易层
我在每个方法调用的开始/结束处添加了日志跟踪(BEGIN、END),以显示处理该方法需要多长时间。
public ListAdvertisementResponse ListAdvertisement(ListAdvertisementRequest request)
{
LogManager.Write("BEGIN - ListAdvertisement", LogCategory.Event);
var response = new ListAdvertisementResponse();
try
{
response.Advertisements = new List<AdvertisementType>();
var ads = AdvertisementDataContextInstance.Advertisements;
foreach (var ad in ads)
{
AdvertisementType advertisement = ConvertToAdvertisementType(ad);
string filePath = AdFilePath + @"\" + ad.Code;
if (Directory.Exists(filePath))
{
string[] files = Directory.GetFiles(filePath);
foreach (string file in files)
{
advertisement.Files.Add(file);
}
}
response.Advertisements.Add(advertisement);
}
}
catch (Exception ex)
{
response.ErrorAction = ResponseActionEnum.GeneralException;
response.ErrorDetails = ex.Message;
response.ErrorMessage = "Unable to list advertisements.";
}
LogManager.Write("END - ListAdvertisement", LogCategory.Event);
return response;
}
业务层日志跟踪
**Timestamp: 2/04/2013 9:23:08 AM**
Thread Name:
Category: Trace
Severity: Information
Message: Initiated AdsManagement.AdsManagentService.ListAdvertisement()
**Timestamp: 2/04/2013 9:23:08 AM**
Thread Name:
Category: Event
Severity: Information
Message: Authentication token validated in AdsManagement.AdsManagentService.ListAdvertisement()
**Timestamp: 2/04/2013 9:24:02 AM**
Thread Name:
Category: Event
Severity: Information
Message: Response received by AdsManagement.AdsManagentService.ListAdvertisement()
**Timestamp: 2/04/2013 9:24:02 AM**
Thread Name:
Category: Trace
Severity: Information
Message: Completed AdsManagement.AdsManagentService.ListAdvertisement()
**TRANSACTION LAYER LOG TRACE**
**2/04/2013 9:24:02 AM** - BEGIN - ListAdvertisement
**2/04/2013 9:24:02 AM** - BEGIN - ConvertToAdvertisementType
2/04/2013 9:24:02 AM - END - ConvertToAdvertisementType
2/04/2013 9:24:02 AM - BEGIN - ConvertToAdvertisementType
2/04/2013 9:24:02 AM - END - ConvertToAdvertisementType
2/04/2013 9:24:02 AM - BEGIN - ConvertToAdvertisementType
2/04/2013 9:24:02 AM - END - ConvertToAdvertisementType
**2/04/2013 9:24:02 AM** - END - ListAdvertisement
As you can see, there is roughly a 1 minute delay before the Transaction layer receives the request. I have no idea what is causing this. I think it might be the logging system (Microsoft.Practices.EnterpriseLibrary.Logging). I've noticed that it creates a separate log file almost every time it receives a request, almost as if the original log file is being kept open which stops it from writing to that file. Perhaps there is a 1 minute timeout on the logging before it decides to create a new log file and write to that?
I have the following log files in the logging directory for today's date: Every time I send a new request to the Transaction Layer, there is a 1min delay and then it creates a new log file:
RTITraceGeneral.log 02/04/2013 9:20 AM
RTIEvent.log 02/04/2013 9:20 AM
c9d64c18-80d9-4993-b167-2070190fce51RTITraceGeneral.log 02/04/2013 9:20 AM
a7acf427-a919-4fe4-9832-d186e9e28c0cRTIEvent.log 02/04/2013 9:24 AM
8e35dbdc-3c94-4e93-866a-3affcbf5f082RTITraceGeneral.log 02/04/2013 9:24 AM