Aspnetcore: Non-serialized hub invocations

[Tragetaschen]

I have tried to circumvent the missing stream invocations in the Java client by introducing for each streaming method on my Hub a sibling method that would await and return the next value that a ChannelReader would provide. The client would then have to immediately invoke the same method again after receiving a value to simulate continuous values. In my C# design validation client, I try to invoke two methods, run Task.WhenAny and then re-issue the finished invocation.

However, the invocation serialization from 1957655653608fa17803308c98153586f6623597 means that any additional incoming message on the connection will only be dispatched when a running (async-blocking) invocation has finished. This includes any second invocation, a new streaming invocation and (which is where it's likely getting interesting) any form of graceful connection abort from the client. As far as I could see in the code for the latter case, all forms of Abort (which would trigger the cancellation token) originate from outside the dispatch loop, so only actually reading from the input pipe can close a connection which is blocked by the running invocation.

So: Personally, I'd love to see lifting the restriction around non-streaming invocations...

[anurse]

We can revisit this in 3.0. We intentionally disabled concurrent invocations because there was some concern around memory issues. We lifted the restriction for streaming invocations because they don't make sense with that restriction. We can revisit this though in 3.0

[BrennanConroy]

For design: Here is a short conversation about making the invocations serial https://github.com/aspnet/SignalR/pull/2086#discussion_r182607396

[anurse]

Let's talk about a design for this in preview 4 (implementation may wait). We probably need this to be opt-in behavior to reduce the risk of user async code going haywire.

[anurse]

Sounds like this may be important for Razor Components (cc @SteveSandersonMS @davidfowl @rynowak @javiercn)

[SteveSandersonMS]

@anurse It's not required for Razor Components, because Razor Components has its own sync context anyway. As far as SignalR is concerned, all the calls into ComponentHub are fire-and-forget (or will be, once we fix one outstanding bug).

[davidfowl]

We should do this regardless.

[anurse]

@davidfowl I don't disagree, it just doesn't align with any of our epics so the prioritization is a little different. If Razor Components had required it, that would have changed the prioritization.

[davidfowl]

@anurse Where is the "we have bugs" epic?

[anurse]

Proposal via @halter73:

We call your Hub method in a loop "serially". However, once you go async and return a Task. When you do that, we will observe the task completion and log errors but no longer block the pipeline.

Addition from @anurse:

Should we provide a setting to limit the number of concurrently running Hub methods?

[ddweber]

Are there any updates on this? I think in regard to long running server methods this can be considered a blocker like stated in #10257 (Client timeout..). The suggested workarounds are not really helpfull neither. And it has been moved around for quite some time.

_Waiting on this issue to be resolved my workaround was to increase the hubOptions.ClientTimeoutInterval temporarly, but this leads to other problems.._

[anurse]

It's in the 5.0 milestone. We'll look at it then.

[halter73]

The suggested workarounds are not really helpfull neither.

While I agree it would be better to allow non-serialized hub invocations for all invocation types, streaming invocations do allow for parallel hub method calls from a single client.

Why is this workaround not helpful @ddweber?

[ddweber]

Quote from @anurse in #10257:

Another super hacky way you could do this is with the streaming support, since we don't block the message loop on those requests. You can just stream only a single item back :). It's a big hack though and a breaking change to your Client if you switch back and forth between streaming and non-streaming.

For development that is ok but once deployed in production that is really a breaking change..
All client implementations will need to be refactored/updated.

[ddweber]

@halter73 Another problem i am facing is that the java client does not support streaming by now (according to this documentation)..

[halter73]

@ddweber The doc link you posted is for version 2.2 of the Java client. In 3.0, the Java client does support server-to-client streaming which is all that's necessary for non-serialized hub invocations.

[anurse]

I'd also suggest looking at our top-level client features matrix: https://docs.microsoft.com/en-us/aspnet/core/signalr/client-features?view=aspnetcore-3.0 it's a good way to view the supported features and which versions support them.

[ddweber]

Oh my fault, sorry. I did not notice that my bookmark pointed to a fixed older version :(
Thank you both! :) I´ll give it a try.

[anurse]