I was searching through Internet, and what I've found is just it is not possible on Azure external/internal endpoint...
How does Windows Azure perform load balancing?
But what I am looking for is, whether session affinity is possible on Service Bus. I even done my own research, with modified EchoSample, but with no success. I've tried ws2007HttpRelayBinding and netTcpRelayBinding and end up with:
System.ServiceModel.CommunicationException: The remote endpoint no
longer recognizes this sequence. This is most likely due to an abort
on the remote endpoint. The value of srm:Identifier is not a known
Sequence identifier. The reliable session was faulted.
So, the question: It is possible to do "service bus load balancing + session affinity"?
There is no way to have sessions persist across Azure to my knowledge. You cannot make any assumptions about which node you will get due to node availability changes. If you need session state - you need to manage it externally from the front end bus (azure database, azure storage, remote db, remote storage etc.). This can be potentially one of the issues with the cloud - you don't get total control anymore. You just have to get creative with how you solve it.
Related
If one application have Azure serviceBus, EventHub in diff Azure Namesapces, web application and also other azure services (eg: cognitive services). can these be accessed with one URL by using Gateway or Load balancer or traffic manager or any other option ?
My problem is - if we have diff namesapces, we need to whitelist every time when there is new Namespaces and it could so too much of a work. so wondering if we can have one common DNS/URL that would make life easier.
Today, Service Bus and Event Hubs don't support any sort of network gateway. This is due to fact that namespace in the connection string used for authorization purpose at the service side.
To add a bit of context to Serkant's statement, support for this scenario is something that is on our roadmap, and hopefully in the near term. Unfortunately, I don't have a date to share currently. The work is being tracked [here] should you wish to keep an eye on it.
We are considering of a design pattern where
Web service tries to insert data into database
If that call fails and db is not available
then we pass that data into azure service bus
Once the db is back up, some other service will read data from service bus and insert into database.
I personally have not seen this pattern however is there any issue with this design ?
The way queuing system are usually used is slightly different from what you're asking.
Queues allow reliable command execution if the destination resource is not available (database) and balance the load on the resource rather than overwhelming it.
The steps would be:
Web service sends a Service Bus message with the data that needs to be inserted into the database.
A backend service is peeking the messages and tries to insert into the database.
If the operation is failing or the database is not available, the message is retried.
I am trying to make my Service Fabric service, which makes a SOAP call to an external service, such that if deployed over 2 or more clusters, it can still work, in that if one service has made the connection to the external service, then the service in the other cluster doesn't try to make the connection, and vice versa.
I can't think of a better way to design this without storing the state in a database, which introduces a host of issues such as locking and race conditions, etc. What are some designs that can fit in this scenario. Any suggestions would be highly appreciated.
There is no way to do that out of the box on Service Fabric.
You have to find an approach to orchestrate these calls between clusters\services, you could:
Create a service in one of the clusters to delegate the calls to other services, and store the info about connections on a single service.
put a message in a queue and each service get one message to open a connection(this can be one of the approaches used above)
Store in a shared cache(redis) every active call, before you attempt to make the call you check if the connection is already active somewhere, when the connection close you remove from the cache for other services be able to open the connection, also enable expiration to close these connections in case of service failure.
Store the state in a database as you suggested
I have a set of user-specific stateful services servicing requests forwarded from a public-facing stateless service (web API) in an app.
I'm trying to delete a stateful service if it has not serviced any user request since a given time interval, say an hour. Currently, I'm managing this by keeping a .NET timer in the service itself and using the tick event to self-destruct the service if it's been idle.
Is this the right way to do it? Or is there any other more efficient approach to do this in Azure service fabric?
The mechanism you have will work great and is what we'd normally recommend.
Another way to do it would be to have a general "service manager" service that periodically checked to see if services were busy, (or were informed) and which could kick off the deleteserviceasync call. That way only that service would need the cluster admin rights, while all the others could get locked down to read only.
I have read the following from Azure in Action book:
"In Windows Azure, the state server, or out-of-process session state provider,
isn’t supported"
Can anyone tell me why this is not supported. They do not explain in the book. I would have thought I could run the state server and all web roles would be able to use this to read session data.
Thanks for replies
Windows Azure has the AppFabric Cache, which is well-suited for session storage. This went live about 2 weeks ago. You can see details in my StackOverflow answers here and here.
I can't give you an absolute answer on the lack of state server, other than the fact that until recently, Web Roles ran under Hosted Web Core instead of Full IIS and that might have had an impact on offering state server. Additionally, since all of your web role instances are equivalent, how would you specify which is the state server? And what happens if Windows Azure recycles that instance? I think this would be a big headache.
With the AppFabric Cache solution, this is cache-as-a-service, completely independent of your role instances, and managed for you. You simply get an endpoint, attach to the cache, and execute puts and gets on name/value pairs. Through the Azure portal, there's a Client Configuration button you click, and a magic chunk of xml gets generated for you - you place that in web.config, and you now have a custom session state provider that stores/retrieves session data to/from cache.
EDIT: On using SQL Azure for session state: SQL Azure doesn't have a SQL Agent, so you wouldn't have a background job periodically clearing the cache. There's an MSDN blog post showing how to get SQL Azure working as a session state provider (and using a worker role background process to perform session cleanup). However, I'd still recommend the AppFabric Cache solution.