liammorrow / orgnalr Goto Github PK

Ideally we can get some integration tests going that will check all the various message passing / recovery mechanisms

Microsoft had previously blessed the SignalR.Orleans backplane as an official backplane for SignalR. https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-7.0#third-party-signalr-backplane-providers I was thinking it might be a good idea to try and engage with the very active Discord community for Orleans https://discord.gg/vByufzUJ and find out what all might be required for this project to get the same. There's some obvious low hanging fruit like documentation and testing but wanted to ask first and see if that was a direction you'd be interested in the project going. To my knowledge it's the only functioning Orleans 7 backplane and has the benefit of not requiring Streams. Potentially even more attractive now that streams has been split off into a separate nuget and the underlying tech they used (SimpleMessageStreams) replaced with Broadcast channel. The SignalR.Orleans team has been completely unresponsive to discussions about upgrading to Orleans 7 and I've gotten no traction in the Discord channel about it either.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Update dependency @types/react to v18.2.79

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update orleans monorepo to v8 (major) (Microsoft.Orleans.Client, Microsoft.Orleans.Sdk, Microsoft.Orleans.Server)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Need to include a getting started guide in the readme

We need some sample projects that highlight how to use OrgnalR.
A SignalR server, and an Orleans Silo should be configured to use OrgnalR, perhaps adapted from example projects in SignalR core.

Describe the bug
Nuget package installation fails and rolls back. There's a conflict with this package which is used by the generated code for a new project: Microsoft.ServiceFabric.AspNetCore.Kestrel.

To Reproduce
Steps to reproduce the behavior:

1. Create a new Service Fabric Application in Visual Studio.
2. From the cluster project (orange icon): right click, Add, "New Service Fabric Service...".
3. Select "Stateless ASP.NET Core", provide a name "Test.SignalR", and hit the Create button.
4. Attempt to add the SignalR.Orleans Nuget package to the new ASP.NET Core service project.

Expected behavior
The Nuget package is added and can be used.

I tried to fire up the ChatApp example and I can't get it going. Here's everything I tried:

Open chatapp solution in vs 2022
Configure multiple startup projects -> 404

Manually run the ChatApp.Silo and ChatApp.Server projects via dotnet run - This works, but I can't get hit a URL

Manually run the ChatApp.Silo and ChatApp.Server projects via dotnet run then run yarn start for the chatapp project

That brings up the chatapp html page but it can't connect to the backend stuff

I tried running things in VS code and couldn't get that to work either.

Am I missing a short path to victory here?

Describe the bug
Right now the backplane waits an arbitrary 5 seconds before subscribing to messages. This is to give the IClusterClient time to be ready - if it's not ready it will throw a null pointer exception (can see this when running the example project and removing the delay).
Delay: https://github.com/LiamMorrow/OrgnalR/blob/master/src/OrgnalR.Backplane/OrgnalRHubLifetimeManager.cs#L81

To Reproduce

1. Remove the Task delay at : https://github.com/LiamMorrow/OrgnalR/blob/master/src/OrgnalR.Backplane/OrgnalRHubLifetimeManager.cs#L81
2. Run the example project

Expected behavior
No null pointer

Additional context
Orleans provides hooks into its lifecycle via the LifeCycleParticipant interface. This could likely be used to delay subscribing until it is ready:
https://learn.microsoft.com/en-us/dotnet/orleans/implementation/orleans-lifecycle

Need a getting started guide in the readme

We're using this library in production for sending non-critical signals to users. Over time we notice a degradation in performance and an increase in memory consumption until at some point we get an application restart with an OOM message.

We suspect the problem is with RewindableMessageGrain. As its associated to Clients (which come and go) and persists messages in state, State however is not cleared when the client goes away and will always stay persisted.

2 relatively easy wins would be to never persist when MaxMessageRewind is configured as 0 and to make persistence optional. A proper fix would involve observing the client and clearing state when the client goes away.

We're using MemoryStorage which exacerbates the issue. If we were to use a proper storage provider then we would expect to see an ever increasing db size.

I'm happy to contribute here.

Is your feature request related to a problem? Please describe.
In this commit on June 6 dotnet/orleans@cbee643#diff-1fcbe03001be1589b2f0995d055a1cec02147c50ba2421171f9b895f3d96b65a they enabled the nullable annotation context. This creates compilation errors with the WriteStateIfDirty method.

I discovered this investigating this stack trace running OrgnalR in a project updated to the latest version of Orleans (7.2.1) Here's the stack trace we got

System.MissingMethodException: Method not found: 'System.Threading.Tasks.ValueTask Orleans.Runtime.GrainReference.InvokeAsync(Orleans.Serialization.Invocation.IInvokable)'.
   at OrleansCodeGen.OrgnalR.Backplane.GrainInterfaces.Proxy_IAnonymousMessageGrain.global::OrgnalR.Backplane.GrainInterfaces.IAnonymousMessageGrain.SubscribeToMessages(IAnonymousMessageObserver arg0, MessageHandle arg1)
   at OrgnalR.Backplane.GrainAdaptors.GrainMessageObservable.SubscribeToAllAsync(Func`3 messageCallback, Func`2 onSubscriptionEnd, MessageHandle since, CancellationToken cancellationToken)
   at OrgnalR.SignalR.OrgnalRHubLifetimeManager`1.CreateAsync(IActorProviderFactory actorProviderFactory, IMessageObservable messageObservable, IMessageObserver messageObserver, IMessageArgsSerializer messageArgsSerializer, ILogger`1 logger, CancellationToken cancellationToken)
   at OrgnalR.SignalR.SignalRExtensions.OrgnalRHubLifetimeManagerFactory`1.OnConnectedAsync(HubConnectionContext connection)
2023-07-21 19:39:28.822 +00:00 [Information] [bingodaubcity-server-api] [790c61fc-b067-4c12-9f9d-30df6b663856] [Serilog.AspNetCore.RequestLoggingMiddleware] HTTP "GET" "/Game" responded 101 in 81.2067 ms

Describe the solution you'd like
I'd like for OrgnalR to work with the latest versions of Orleans

Describe alternatives you've considered

Additional context
If you update the Orleans nugets in the OrgnalR project to the latest version, you'll get a few compiler errors related to the aforementioned nullable annotation context. If you pass in string.Empty for state instead of null the compilation issues go away and all the tests pass. I'm not sure if that'll fix my particular issue, but that's probably a fix you'd want to make anyway. I would submit a PR, but it's exceptionally trivial and I'm not certain of just putting in string.Empty is an acceptable fix for the situation.

Thanks for all your work to make this library! Do you have plans to upgrade this to .net 7?

Is there an intention to implement the HubContext (or is there something I'm missing) so that messages can be sent from a grain to a hub?

https://github.com/OrleansContrib/SignalR.Orleans#hub-context