Are timer caveats documented somewhere?
There seems to be a few gotchya's like this (others being reentrancy, not going through grain interceptors) compared to other flows of grain code execution (grain calls / stream callbacks / reminder receives).
dotnet/orleans#2574 relates to the reentrancy issue.
I'm trying to debug an issue where stream messages sometimes don't get delivered. We're using SQS / DynamoDB / and auto scaled orleans silo instances using Fargate.
Looking at Orleans source code, I think there's a scenario where PersistentStreamPullingAgent.ReadFromQueue will cause messages to be deleted (rcvr.MessagesDeliveredAsync) before ever delivering the messages. If https://github.com/dotnet/orleans/blob/d360b539784b14a73ceb357fd6b5084d3116e9d9/src/Orleans.Runtime/Streams/PersistentStream/PersistentStreamPullingAgent.cs#L473 that line is hit, there is no guarantee that the messages added to the queue cache (on line 441) have been sent at all. A subsequent execution of PersistentStreamPullingAgent.ReadFromQueue would get those undelivered messages from queueCache.TryPurgeFromCache because SimpleQueueCache only excludes items marked as DeliveryFailure, which could only happen if there was actually an attempt to deliver the messages. The messages would then get deleted from the underlying message queue (in our case SQS) having never been delivered to the consumer.
Am I missing something, or does that sound plausible?
Hi there, this may be an odd question but we're looking for some advice on long running external tasks. Can some grains have a higher response timeout / turn warning threshold because we know they're going to be waiting on an external task. We've given the orleans thread back to the thread pool because we're on an await so are there any issues? It seems easier than making the external task switch context into Orleans to execute a callback after the external task is finished.
@ReubenBond do you have any thoughts on @Romanx 's question here?
Hello all. I have a use case for an application I am building using orleans and I am not 100% sure how to go about it. I was hoping to get some input from this forum.
I have several applications that I must interface to. These applications are not web based and they use UDP or TCP as their transmission mechanism. My application has several grains that must parse the received data (either UDP/TCP). I am trying to abstract away the mechanism used to send the data (UDP vs TCP). Therefore my initial idea was to have several Grain Clients in charge of dealing with TCP/UDP connections and then sending the data to the actual Grain.
My application will sit behind a load balancer and must be highly reliable and redundant. My application will in some instances push data via the client grains or in some other instances receive data and respond (poll/response).
This means that a connection, no matter who initiated it, must only be handled from a single grain client however multiple grain clients must exist in different servers so that if a server fails another grain client can take over.
My inital though was to use streams to handle the communication between the grains and the grain clients. However since only one grain client must be sending or receiving data, I really don't want to broadcast the data to all grain clients. Instead I was thinking about using the stream in a competing consummer fashion, but this is not somehting (that I know) available already in the streams provided by orleans. Things get a little bit more complilcated when using TCP as this is a connection oriented protocol. In this case, not only the data must be sent to a single client, but it also must be sent to the same grain client that currently has the active TCP connection.
I found https://stackoverflow.com/questions/55021791/orleans-custom-tcp-socket-connection this online and at the moment I am thinking of having the grain itself act as the socket server and completly eliminate the use of grain clients. Hopefully this all makes sense to you. Thank you for your time.