Audit / Error / ServiceControl Queue Configuration

224 views
Skip to first unread message

Jesse Inskeep

unread,
Jun 3, 2015, 6:09:24 PM6/3/15
to particula...@googlegroups.com
Product name: nServiceBus
Version: 5.2


My team is currently working on some some configuration related to how our nServiceBus endpoint interact with ServiceControl.

Our current configuration has both ServiceControl and out application endpoints (NSB Hosts) on the same server. We can see where this might cause some load issues and are working on moving ServiceControl (and ServicePulse) to a separate server from our application server.

Currently our app.config files have this (irrelevant information omitted):

<configSections>
    <section name="MessageForwardingInCaseOfFaultConfig" type="NServiceBus.Config.MessageForwardingInCaseOfFaultConfig, NServiceBus.Core" />
    <section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core" />
    <section name="AuditConfig" type="NServiceBus.Config.AuditConfig, NServiceBus.Core" />
  </configSections>

  <MessageForwardingInCaseOfFaultConfig ErrorQueue="error" />
  <AuditConfig QueueName="audit" />


Via the Particular documentation looks like we can define the error and audit queue at the machine level (http://docs.particular.net/nservicebus/operations/auditing). We ran this and pointed the queues at the new ServiceControl server, but the messages went to the same server the application was hosted on.

I then removed the configSections and associated MessageForwardingInCaseOfFaultConfig and AuditConfig pieces from the app.config file thinking that since we had them in the app.config that it was overwriting configuration specified at the machine level.

This threw an error saying we need to add <add key="ServiceControl/Queue" value="particular.servicecontrol@servicecontrolservername"/> to the "appSettings" node. We did this and everything worked!

The only problem is that now our configured is spread out with the error and audit queue definition in the registry while the ServiceControl instance is defined in the app.config file... (which will modify for each environment via tokenization in TFS Release Management). The whole reason we went down the "machine configuration" route was the hope that we could control the ServiceControl instance for all endpoints on a server without any code changes (we have about 60 endpoints on that server right now).

It got me wondering if we even needed to define the audit and error queue destinations (in app.config or machine level) if we add the "ServiceControl/Queue" to the app.config. Some of the documentation alluded to that, but I might have misinterpreted...

Secondly, can we somehow move the "ServiceControl/Queue" key to the registry as well to maintain this at a machine level?

If we can't set the "ServiceControl/Queue" key value at a machine level, then I would say we shouldn't set the error / audit queues at  that level either. Seems like it could cause developers some headaches down the road having conflagration in two different places.

Any suggestions or recommendations are welcome! :)

ramon...@particular.net

unread,
Jun 8, 2015, 1:00:29 PM6/8/15
to particula...@googlegroups.com


Hi Jesse,


To share settings between all endpoints you can add the relevant settings to the appSettings of your `machine.config`

Be sure to put them in the correct .net framework folders that are relevant

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config


We use the `ConfigurationManager` internally:



You cannot use the registry for this and, unfortunately, there is no way to override the implementation that reads the settings.


Does this help?


Regards,
Ramon





On Thursday, June 4, 2015 at 12:09:24 AM UTC+2, Jesse Inskeep wrote:
Product name: nServiceBus
Version: 5.2


My team is currently working on some some configuration related to how our nServiceBus endpoint interact with ServiceControl.

Our current configuration has both ServiceControl and out application endpoints (NSB Hosts) on the same server. We can see where this might cause some load issues and are working on moving ServiceControl (and ServicePulse) to a separate server from our application server.

Currently our app.config files have this (irrelevant information omitted):

<configSections>
    <section name="MessageForwardingInCaseOfFaultConfig" type="NServiceBus.Config.MessageForwardingInCaseOfFaultConfig, NServiceBus.Core" />
    <section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core" />
    <section name="AuditConfig" type="NServiceBus.Config.AuditConfig, NServiceBus.Core" />
  </configSections>

  <MessageForwardingInCaseOfFaultConfig ErrorQueue="error" />
  <AuditConfig QueueName="audit" />


Via the Particular documentation looks like we can define the error and audit queue at the machine level (http://docs.particular.net/nservicebus/operations/auditing). We ran this and pointed the queues at the new ServiceControl server, but the messages went to the same server the application was hosted on.

I then removed the configSections and associated MessageForwardingInCaseOfFaultConfig and AuditConfig pieces from the app.config file thinking that since we had them in the app.config that it was overwriting configuration specified at the machine level.

This threw an error saying we need to add <add key="ServiceControl/Queue" value="particular.servicecontrol"/> to the "appSettings" node. We did this and everything worked!
Reply all
Reply to author
Forward
0 new messages