Reputation
Top tag
Next privilege 125 Rep.
Vote down
Badges
5
Impact
~1k people reached

  • 0 posts edited
  • 0 helpful flags
  • 3 votes cast
Sep
24
awarded  Autobiographer
Nov
23
comment Custom .NET apps and clustering
exactly. that is what I am using, always transactional...and also durable (on disk in case of failure of power or whatever).
Nov
22
awarded  Student
Nov
22
awarded  Scholar
Nov
22
awarded  Supporter
Nov
22
comment Custom .NET apps and clustering
[cont]... Because, in this specific solution, it is WCF and Transactional MSMQ processing msgs from the queue. If a node, or app, goes down then the others kick in and MSMQ/WCF co-ordinates who/which app gets that msg to process without duplicate processing (WCF config for setting ExactlyOnce=true). So that works fine. But for other custom apps, you are right - you need to know at what point was the app doing what and if it needs to be processed FROM That point onwards, or all over again when the node fails over.
Nov
22
comment Custom .NET apps and clustering
Walter - great response. Thank you. + 1 to that. OK so here is the thing: If your app "dies" because of the node rebooting or hardware error then Node y kicks in. Fine but then I guess you are right that your app needs to know what it was working on so it can resume where it left off. It makes sense - I just thought there would be another special way of doing this but guess not. For a solution I proposed, which works, is to have n instances of a console app run across the nodes for scalability and HA which is bound to MSMQ. Works like a treat
Nov
22
accepted Custom .NET apps and clustering
Nov
22
comment Custom .NET apps and clustering
Both I guess. I'm trying to gain more knowledge on this subject matter which also stimulates me :)
Nov
21
awarded  Editor
Nov
21
asked Custom .NET apps and clustering
Nov
21
revised Clustering and custom applications
splitting questions into 2
Nov
21
asked Clustering and custom applications