Local connection string of service bus - servicebus

I have a on-premise service bus installed i want to browse and test in service bus explorer . How can i know the endpoint of my service bus installed locally and details step by step procedure to test on service bus explorer. Like shared secret key all the attribute values in endpoint

The connection string looks something like this
Endpoint=sb://<hostname>/ServiceBusDefaultNamespace;StsEndpoint=https://<hostname>:9355/ServiceBusDefaultNamespace;RuntimePort=5671;ManagementPort=9355;TransportType=Amqp
The ports are the default when configuring and should be changed accordingly if required.
One thing to note is that the newer releases of Service Bus Explorer do not support Service Bus for Windows Server (which itself is out of mainstream support) and you would need to use v2.1 which last supports it.
Since there seems to be no releases available, you will have to fetch and run the code directly.

Related

Installing Service Bus for Windows Server

I am looking at the diagram at Service Bus For Windows Server : Supported Topologies
My question is, in 2 tier deployment, can i install Service Bus Gateway on Machine1, Service Bus Broker on Machine2 and Windows Fabric on Machine3 or that diagram means i install all these 3 components on same machine and have 3 machines like that and create a farm?
Also i am little confused as what do they mean by "Service Bus Host"? Does it mean a system that has Service Bus Gateway, Service Bus Broker and Windows Fabric (all 3 components) installed on it or just Service Bus Broker?
You must install all 3 components together on one node. You can decide to put the databases on another server but the services get installed together.
Therefore the term service host probably would mean all three.

Auto-start appfabric seems to work sequentially

I have a couple of wcf services which will call a registration service at startup (through a custom ServiceHostFactory). All these services (including the registration service) are running in the same app pool. I installed appfabric to auto-start all the services. I won't explain all the detailed settings (because I think it's not necessary yet), but in short, the services use net.tcp bindings and is running in IIS 7.5 on Windows 7.
The problem:
When I set all services to auto-start it will begin with one (random) service, this service tries to connect to the registration service. But somehow this registration service won't start-up. It looks like it wants to start all services sequentially.
The (not wanted) solution 1:
When I put the registration service in it's own app pool everything works fine and alle services come online in a matter of seconds and register themself.
The (not wanted) solution 2:
When I disable the auto-start and try to access one of the services after a iisreset, it all works fine. The service will try to register itself and the registration service in his turn will start.
I'm new to appfabric, so it might be some simple configuration issue. The weird thing though is that it won't work whith auto-start, but seems to work fine with a manual start.
Any idea's?
There is no priority in AppFabric Auto Start feature. You can't assume that one service will always be started before the others. Also, you can't assume they will start all at the same time.
For the specific scenario, it's recommanded to use WCF 4.0 Discovery and Announcement. Announcement feature enables service to announce their availability (by sending Hello and Bye announcements) whereas Discovery feature allow clients to discover service address at runtime.
All your services are on the same server ? could be pertinent to use a namedPipeBinding.

Simulating a transient error for Service Bus

I'm writing an application which will use the Azure Service Bus. For local development I'm using Windows Server Service Bus to provide the same services (the code to use either is identical).
I want to write the application to be tolerant of transient errors when sending or receiving messages. To that end, I want to be able to test the fault-handling code can deal with the local Service Bus instance suddenly being unavailable during execution of various operations.
Ideally, I'd want to write some automated integration tests around these scenarios, but I appreciate that may not be practically achieved.
What can I do to simulate transient errors on my local Service Bus?
One easy thing would be to call the stop-sbservice (affects one node) or stop-sbfarm (affects the entire farm) cmdlets. This would let you simulate a servicebus outage locally. You can then call start-sbservice or start-sbfarm to bring the service back and validate that your code recovers properly. This approach also has the added benefit that you control when the service returns (compare to just crashing the process). This page has information on the available cmdlets.
If that's not enough, another approach that I've used in the past is to shut down the network interface, or, if the server is in another machine, put up a firewall on the ports used to communicate to service bus.

How to create a local Windows-based service bus outside of Azure, similar to Redis with automatic fail-over?

We are implementing a service/message-bus feature in our SignalR application and have been looking at Redis, with automatic fail-over using Redis Sentiel. We would like to maintain our own servers and have read SignalR powered by Service Bus. Since this is a Winddows Azure implementation, how can I accomplish this in our internal network with VM's with automatic fail-over similar to the Redis solution discussed above?
You may want to look at Service Bus for Windows Server:
http://msdn.microsoft.com/en-us/library/windowsazure/jj193022(v=azure.10).aspx
It has API symmetry between Azure Service Bus and the Windows Server API (particularly for messaging: queues and topics/similar to SignalR). It doesn't include the caching and ACS services. However, if you want the Azure Service Bus - Caching...you can get that in:
AppFabric for Windows Server
http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx

How to renew subscriptions after IISRESET?

This is my scenario:
Web application with a self-hosted bus (publisher)
Windows service with NServiceBus.Host.exe (subscriber)
Imagine that trigger an IISRESET (never mind on the why I have to do that) that makes the bus re-initialize and lose the subscriptions that already had. I'm using MsmqSubscriptionStorage and the publisher (web app) implements the IAuthorizeSubscriptions interface.
How can I renew the subscriptions and also call the AuthorizeSubscribe()? Is that possible? What's your suggestion to this scenario?
If NServiceBus is properly using MsmqSubscriptionStorage, then after iisreset, the bus should initialize and load the existing subscriptions from the configured storage queue. This queue name can either be set by configuration or, if omitted, should default to a name based on an assembly plus "_storage". However, having never used this from a web application, I don't know what that would be in that scenario, since there is no class that implements IConfigureThisEndpoint.
That said, trying to publish an event from a web application is a very icky business, and it's generally advised that you avoid just that.