I'm using TopShelf right now with RSB, but be forewarned, the TopShelf
"shelving" support is not fully baked. When I last tried it (~1 month
ago - could have changed since, haven't been keeping track) the
auto-restart capabilities were not working as advertised yet. It's a
neat concept but just not there yet. I don't like a lot of projects
either, so what I'm doing is spinnging up RemoteAppDomainHosts for
bootstrapper types that I find. Currently all of my endpoints are in
one assembly, so I'm just scanning the types in that assembly looking
for types derived from my bootstrapper base type (little special sauce
on top of the RSB AbstractBootstrapper) but could expand that to do
full assembly scanning within the app directory if needed. I then have
a config file per endpoint, and they get spun up in separate app
domains inside the main TopShelf-based service host executable like
so:
foreach (var bootstrapperServiceName in bootstrapperTypes.Keys)
{
string serviceName = bootstrapperServiceName;
x.ConfigureService<RemoteAppDomainHost>(s =>
{
var type = bootstrapperTypes[serviceName];
s.Named(serviceName);
s.HowToBuildService(name => new RemoteAppDomainHost(type)
.Configuration("Config/" + serviceName + ".config"));
s.WhenStarted(host => host.Start());
});
}
I don't have auto-restart - don't know if I'll need it yet - but
beyond that it's working very smoothly. Installing the service is as
simple as:
HostName.exe install
Pretty happy for the time being.
Thanks,
Matt
2011/2/3 João Bragança <[email protected]>:
> Definitely gonna take a look at Topshelf for this. Don't really want
> to give each of my consumers a separate project like Udi suggests.
> Looks like I might be able to make a subdirectory and drop a .config
> inside for each message consumer with the ShelfConfiguration section.
> Then come up with a convention to define all the default endpoints for
> commands and programatically configure each bus instance.
>
> On Thu, Feb 3, 2011 at 12:34 PM, Corey Kaylor <[email protected]> wrote:
>> I'm actually a fan of Udi's approach and isolating consumers / sagas into
>> individual endpoints. It wouldn't be too hard to manage if using something
>> like Topshelf that can spool up an appdomain for each folder under a
>> /Services folder where an assembly implements something like IBootStrapper.
>> I had plans to incorporate a hosting option that uses Topshelf for this
>> reason.
>> By having all your messages in separate endpoints they will no longer
>> compete with each other for things like this and will typically perform
>> pretty well on one thread. Also when a subscriber goes down, it doesn't
>> affect the SLA of other things trying to send messages to other subscribers
>> unrelated to the one that went down. One message handler that takes 30
>> seconds doesn't affect another that is much faster and receives more
>> messages. It also allows you to scale individual components that need to
>> scale, not the entire thing just because a couple don't perform well.
>> Also once you've deployed this way performance counters could paint a very
>> interesting picture of what's going on with your business, not just what's
>> going on with EndpointA that handles 200 types of messages.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Rhino Tools Dev" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/rhino-tools-dev?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Rhino Tools Dev" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rhino-tools-dev?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
