Nservicebus disable default logger in web.config - nservicebus

I'm using the DefaultFactory LogManager for Nservicebus v5. I'm happy with this but was hoping to be able to disable via the web.config.
I use web.config settings, as found in the help docs
<configSections>
<section name="Logging" type="NServiceBus.Config.Logging, NServiceBus.Core" />
</configSections>
<Logging Threshold="Debug" />
I'd prefer not to set the threshold as fatal. I was hoping for a "None" or Disabled="true"
Also can the directory path be set web.config?
Update: Why would we want to ignore errors?
The short is we don't really have write permission on the servers.
The long is this isn't 100% true.
Our systems is moving towards microservices, the problem with this is that decentralized logging is a tracing/visualization nightmare.
So we moved flow tracing, exceptions, and limited tracing to a centralized system.
Programming Entry points (aka message Handlers, web api endpoints, etc) are nearly always wrapped in a try catch log throw on each handler, this covers all our programming errors. This isn't anything really that different to normal.
The centralized logging location sets of all the nice red flashing real time alarms one could wish for.
Which leaves only configuration type error left like missing queues, bad assembly bindings, faulty config files, or more runtime style stuff like IoC wiring (outside of the handler code).
With the centralized logging and monitoring of the error quests, it is fairly easy to detect when the service is broken and if it is then we turn on logging, restart, try the faulty issue, and fix.
Guaranteed delivery will take care of everything else once it is up again :D Gone are the days of 150mb log files spread across 10 different servers.
The simplicity of DefaultFactory was nice, as was not needing another nuget package and associated configuration.
Is this the correct way forward. Many would argue no.
Could we have done it better? yes we could implement the common logger interface and pass it into NServiceBus but we arn't quiet there just yet and the win isn't critical atm.
A side note: One really really nice thing about the way we log is that in our backoffice tool we have been able to simply show the flow for each "order", similar to using a correlation id in greylog.

Since this was not considered a likely scenario it does not have a first class API. But you can achieve this via passing in a null logger from any of the common logging libraries (NLog, Log4net, CommonLogging). I assume you are using one of these in your website.
So take NLog for example.
Install-Package NServiceBus.NLog
The in your webconfig
<appSettings>
<add key="disableLogging" value="true"/>
</appSettings>
Then in your global startup
if (ConfigurationManager.AppSettings.Get("disableLogging") == "true")
{
LoggingConfiguration config = new LoggingConfiguration();
LogManager.Configuration = config;
NServiceBus.Logging.LogManager.Use<NLogFactory>();
}
This is leveraging the approach documented here http://docs.particular.net/nservicebus/logging-in-nservicebus#nlog

Related

NServiceBus configuration in netcore 3.1 Startup

I've gone through all the documentation and examples of setting up NServiceBuse in NetCore, however, all the examples have the configuration being done in the Program.cs (Host.CreateDefaultBuilder().UseNServiceBus()).
I would like to know if I can configure NServiceBus in the ConfigureServices method of Program.cs.
The reason is that in the HostBuilder I'm building up all of the IConfiguration options (e.g. reading from appsettings.json, EnvironmentVariables, AzureKeyVault, ConfigMaps, etc.) and the Logger implementation. By the time ConfigureServices is called, all of those have been resolved. I need to be able to get things like connection strings from the IConfiguration, and so I don't believe it will work to do it in the HostBuilder.
It looks like a lot of work might be being done under the covers to inject the IMessageSession and scan for IHandlMessages instances. That should be able to be done in the Service.
Edit: Forgot to add, because it is in the Program.cs and we are using Serilog, I do not have a LoggerFactory. The LoggerFactory is registered and injected by the Services, but I cannot get it at this point in startup.
Looks like this isn't an option. I was able to have a workaround to get it all working, which is just to put it in the Program() and just make sure it is called after all the other configuration is done. It doesn't seem ideal and seem to be an anti-pattern from where netcore 3 is going.
I'd like to add that this is a poor design choice. I should be able to register my stuff in startup and package scanning shouldn't be happening.
This is a neat project, but I think that for any non-trivial development it may be left lacking.
The reason is that I would like to have a web host with multiple endpoints and I cannot do that without running two full instances (https://docs.particular.net/samples/hosting/generic-multi-hosting/).
My workflow is
message comes in to do all the work
message #1 starts a saga with 100+ messages
each message publishes an update that it is done, so that the UI can check the status of the Saga
The messages from #3 are not handled until all 100+ messages are processed (FIFO).
What I'm wanting to do is have a second queue (we're using Azure service bus) to listen for the worker updates on and update the UI.
Although you already have a workaround I have build a similar setup as you described with with Serilog as logger and NServiceBus. You can access the configuration in Program.cs like so:
public static IHostBuilder CreateHostBuilder() =>
Host.CreateDefaultBuilder()
.ConfigureAppConfiguration()
.UseSerilog()
.UseNServiceBus(c => NServiceBusSetup.Configure(c.Configuration, c.HostingEnvironment))
In the self made method NServiceBus.Configure you can setup your endpoint.

NServiceBus 4.0.4 Subscriber very slow

I have a problem with my publish/subscribe implementation. I'm upgrading from NServiceBus version 2.6 to 4.0.4 and everything seems okay as far as I can understand from the logs but the messages are processed really slowly by the subscriber. I use NServiceBus.Host.exe.
In the old implementation I have configured threads as follows:
<MsmqTransportConfig
ErrorQueue="error"
NumberOfWorkerThreads="40"
MaxRetries="5" />
And the messages go through with nice speed.
In the new implementation I've tried to make the changes needed for the configurations:
<TransportConfig
MaximumConcurrencyLevel="10"
MaxRetries="5"
MaximumMessageThroughputPerSecond="500"/>
Am I missing something critical?
I have a valid license so I should have max threads in use. I haven't got RavenDB or SQL, the implementation uses MSMQ, I've disabled Sagas and TimeoutManager in my subscribers configuration code:
NServiceBus.SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);
Configure.Features.Disable<Sagas>();
NServiceBus.Configure.With()
.DefaultBuilder()
.UseTransport<Msmq>()
.DisableTimeoutManager()
.UnicastBus()
.LoadMessageHandlers();
I did a crude test and the difference in my development environment is so that the 2.6 version handled approximately 80 messages per second and the 4.0.4 version handled approximately 8 messages per second - which is really very bad. So something's wrong here and I just can't seem to find what it is.
Edit: It looks like the problem was generated from our project structure, for some reason the older version of NServiceBus didn't mind our structural approach with generic subsrcriber that uses MEF to load the actual subsrciber-assemblies but the new one went to sleep. I changed the folder structure and now the subscriber works as intended. So the configurations I was using work just fine, but I did delete MaximumMessageThroughputPerSecond from my settings so that it won't present a future problem since the aim is to be as fast as is possible.

Why does HTTP DELETE verb return 405 error - method not allowed for my RESTful WCF service running on IIS 7.5?

Can anyone shed any light on this? I feel like I have wasted the entire day today hunting and searching the internet for any scrap of information about how to do this. I have created a very simple WCF RESTful service. It is basically a proof of concept. I have a simple database behind it and I am just trying to get it working so that I can view, create, update and delete items. Right now I only have view and update working. I'll tackle create later. For now I can't figure out why the delete doesn't work. Almost everything I have found so far tells me that I need to disable the WebDAV module. I did that and then I got PUT to work. But I can not get DELETE to work. Whenever I attempt to call DELETE through my service I get the following error:
The remote server returned an unexpected response: (405) Method Not Allowed.
So it seems like somewhere on my server it is not allowing the DELETE verb. But for the life of me I can not figure it out. I already checked the Handler Mappings and the handler allows all verbs for the .SVC extension. I have disabled WebDAV. I'm not really sure where else to look. I am using IIS 7.5 on Windows Server 2008 R2.
(I can provide code if it would help at all)
Thanks,
Corey
In case anyone having the same issue.
Here is another way you can try.
in web.config
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
I just spent a ton of time trying to figure out why I kept getting 405 Method Not Allowed when using the DELETE verb. Everything I read said to uninstall WebDAV from IIS, but that seemed to break IIS in that all sites gave 503 errors. I reinstalled it, then went about looking in IIS for some setting.
It turns out that WebDAV is the problem, and it has a node on the IIS features page named "WebDAV Authoring". Clicking on that lets you then click on WebDAV Settings... to get the properties page. In the section Request Filtering Behavior, set Allow Verb Filtering to False seemed to do the trick for me (YMMV).
This seemed to be a popular result when googling for a solution, so I thought I'd add to the list of suggested solutions.
Open your website's Handler Mappings in IIS Manager
Edit each handler you want to DELETE with, clicking Request Restrictions, choosing the Verbs tab, then add DELETE to the "One of the following" list or, if appropriate within your concerns, allow all verbs.
You might need to restart your website and/or recompile your code
Well I'm not sure if this is really an answer to my question but it did solve the problem. I simply started a new project in Visual Studio and this time I used the .NET REST Service template that I found online. Then I transferred the old code I had from my previous attempt and used it in the new project. It worked like a charm. All four verbs work correctly now (GET, PUT, POST and DELETE). So it is working now.
Corey

Disable proxy for entire application?

Ever since upgrading to Visual Studio 2010, I'm running into an issue where the first web request of any type (WebRequest, WebClient, etc.) hangs for about 20 seconds before completing. Subsequent calls work quickly. I've narrowed down the problem to a proxy issue.
If I manually disable proxy settings, I don't experience this delay:
Dim wrq As WebRequest = WebRequest.Create(Url)
wrq.Proxy = Nothing
What's strange is that there are no proxy settings enabled on this machine in Internet Options. What I'm wondering is if there is a way to disable proxy settings for my entire project in one shot without explicitly disabling as above for every web object.
The main reason I want to be able to do this is that I'm trying to use an API (http://code.google.com/p/google-api-for-dotnet/) which uses web requests, but does not provide any way to manually disable proxy settings.
I have found some information suggesting that I need to add some proxy information to the app.config file, but I get errors building my program if I make an edits to that file.
Can anyone point me in the right direction?
Brent - that's the correct solution : adding a defaultProxy element to your application's configuration file.
So for a website, it's the web.config. For an .exe application, it's .config.
And those settings are also correct :-
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy enabled="false" useDefaultCredentials="false">
<proxy/>
<bypasslist/>
<module/>
</defaultProxy>
</system.net>
</configuration>
Instead of turning off the proxy setting altogether you can try using the bypasslist to turn it off for the servers that you're having problems with.
See http://msdn.microsoft.com/en-us/library/kd3cf2ex.aspx for details and a sample.
If you're having problems changing the app.config I suggest posting the errors and possibly the app.config as well.

ChannelFactory.CreateChannel and proxy instantiation is slow in WCF

I have a client-server application, in which the client communicates with the server using WCF (WCF is used both in the client and the server).
My problem is, that instantiating the auto-generated proxy in the client, in the following way:
new Service1Client() takes constantly 15.xxx seconds.
I tried to solve this problem, and came to the following results:
1) Compiling and running the same code on other computers, ends up in the same way (always 15.xxx seconds).
2) Instantiating the proxy using ChannelFactory.CreateChannel< IService1 >()
doesn't help (it gives the same result).
My guess, is that whenever the channel factory creates a channel, it tries to do something with a 15 seconds timeout, and when it fails, it continues with creation.
By the way, I use .Net 3.5 without SP1, and cannot upgrade to SP1 :(
Thanks ahead
Even though it is already outdated, it may be useful for somebody else searching for the same. Problem could be with DNS resolution problem, that might be solved in SP1. So you can check if it happens only when you use host name or also with specified IP address.
I've seen this before, where the time was being taken in looking for a proxy server. Check your WinINET (Internet Explorer) proxy settings.
My specific reason for thinking "proxy server" is that it takes 15s. 15s sounds like a nice round number for a network timeout.
Even though this is very old information I just found this issue too although I was experiencing a 7second delay on the First call to a method on the Service Client, I tracked it (in my environment) to Internet Explorer settings as stated above, but in my circumstances it wasn't a Proxy enabled, but the Automatically Detect Settings.
Connections -> Lan Settings and Automatically Detect settings was enabled.
I played with the machine.config and app.config and set
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
Which also made no difference.
I found this answer here and thought I'd contribute a little more information in case someone else in the future experiences something like this.
(This with a .Net 4 WCF service)