Hi @ReubenBond I will try with ConfigureEndpoints but quite confuse about siloPort and gatewayPort value.
In the config server section which following https://dotnet.github.io/orleans/docs/host/configuration_guide/server_configuration.html
The siloPort value is 11111 and gatewayPort is 30000. Can I apply both value in my situation or I need to use another value?
And What happen if the siloPort and gatewayPort value is use by another process?
In the config server section which following https://dotnet.github.io/orleans/docs/host/configuration_guide/server_configuration.html
The siloPort value is 11111 and gatewayPort is 30000. Can I apply both value in my situation or I need to use another value?
And What happen if the siloPort and gatewayPort value is use by another process?
@aghlara_twitter there are people in the community. The best place to ask is the discord server: https://aka.ms/orleans-discord
@GiaNguyenLe you want the ports to be available. If they're in use then the process wont be able to start
@SebasWW Orleans uses a grain directory to find grains. There is some explanation in this video: https://www.youtube.com/watch?v=R0ODfwU6MzQ&t=866s
Hi folks! I'm looking for some advice on long-running, yet fine-grained (no pun intended) operations within a Grain. Imagine a data migration task where a million documents / rows from one data source need to be loaded, converted, and stored to another database. Ignoring failover concerns, is it okay to just have a loop like that within a Grain method?
I'd probably use a reminder and do it in the background, @sunsided. This SO answer demonstrates a long-running background process which is resilient to machine failures: https://stackoverflow.com/questions/71065057/is-orleans-reminder-execution-interleaved/71068896#71068896
1 reply
In the case of millions of docs/rows, assuming that takes a significant amount of time, you may want to store progress somewhere so that you can resume from a recent checkpoint
@ReubenBond Thanks! I did look into Reminders but was a little hesitant because of the "associated with a grain, not any specific activation" notion mentioned in the docs. I assume this just means that any Grain that sets a reminder of a specific name will be woken up? (But it's still tied to the specific instance, i.e. there's not going to be a zero-keyed Grain instance after a wake-up event?)
Yes, so if you have a grain "my-worker/1234", and it sets a reminder, then when the reminder fires, Orleans will find that grain and wake it up. If it's currently active, it will just tell it the reminder fired, but otherwise it will find a place in the cluster to activate it, activate it, and then tell it its reminder has fired
Thanks a million!
Reminder: we are on Discord now: https://aka.ms/orleans-discord
Hello folk, We are looking for a consultant to consider our production plans with Orleans works with Kubernetes, who has already run and manage mission-critical system on Kubernetes with using Orleans. Is there any other special community for this type of needs or can someone who has the required skills contact with me directly here?
Hello Orleans community!
I was trying to implement graceful shutdown for grains when shutting down silo
I was not able to find any description of what the procedure of graceful silo shutdown is and how one can implement graceful shutdown/cancelation for activated/running grains.
Most likely I have missed it. Could somebody point me to where I can find the information on:
- General description of graceful Silo shutdown procedure
- From 1 it should be clear what are the guaranties for running/activated grains and how they can participate in graceful silo shutdown
Thank you!
Please note that we use Discord now: https://aka.ms/orleans-discord
If they take too long (determined by the cancellation token passed by the host, which is configured via
HostOptions.ShutdownTimeout when using the .NET Generic Host), then it stops waiting and promptly terminates
No system should require graceful shutdown to work correctly, since no system can guarantee that shutdown occurs gracefully
And if the finally code call a grain than that Message - will not be delivered, right?
In essence the question is the first one - how to gracefully shutdown (including communication to grains)
I see that Stop creates CTS .. thus most likely not.
For all the grains that are using the service
A strict distributed semaphore would be expensive to implement
Especially if it needs to also be fault tolerant. I would opt for a simpler approach unless you need some precise semantics
@joepvand yes, it's doable. What kind of clustering provider are you using? Best to discuss on discord
Saw that @sergeybykov said the following "Calls (including stream events) to non-reentrant grains should not interleave. Timer callback are the only exception, a bug that became a feature over tme." You could use
this.GetStreamProvider(..).GetStream<T>(id, namespace)from within a grain, but you could as well use IClusterClient.GetStreamProvider(..).GetStream(id, namespace). What is it that defines that the stream is coupled to the grain, because it seems like the two options does more or less the same thing, but the second doesn't necessarily seemed tied to the grain (if it's not done through the streamId). Please advice me.