Signalr: ConnectionManager.GetHubContext<t tclient="">no se transmite a los clientes mientras ConnectionManager.GetHubContext<t>funciona bien</t></t>

Creado en 28 ago. 2015  ·  3Comentarios  ·  Fuente: SignalR/SignalR

Tengo una aplicación web asp.net que aloja un controlador webapi y un concentrador de señal R.
La aplicación tiene una página de lista que detalla una lista de las últimas ubicaciones conocidas de un usuario.

El hub se implementa de la siguiente manera.

public class LocationHub : Hub<LocationHubClient>
{
    public void BroadcastLocationUpdated(string locationName)
    {
        Clients.All.locationUpdatedCallback(locationName);
    }
}
// define an interface for the client side callbacks
public interface LocationHubClient
{
    void locationUpdatedCallback(string locationName);
}

Webapi tiene la siguiente función api que se llama desde un cliente móvil y almacena la posición de los usuarios en una base de datos y luego transmite el nombre de la ubicación a todos los clientes conectados llamando a GlobalHost.ConnectionManager de la siguiente manera.

[HttpPost]
public IHttpActionResult UpdateActivity([FromBody]UserLocationData location)
{
    // store in DB...
    // omitted for brevity

    // update clients...
    var hubContext = GlobalHost.ConnectionManager.GetHubContext<LocationHub , LocationHubClient>();
    hubContext.Clients.All.locationUpdatedCallback(location.name);
}

Estoy pasando dos parámetros genéricos al método GetHubContext para escribir fuertemente mi hubContext con el tipo LocationHubClient.
Este código se ejecuta sin errores pero no transmite el evento a los clientes. Al inspeccionar el objeto hubContext en el depurador, parece que no hay clientes conectados.

Puedo hacer que el código funcione como se esperaba eliminando el segundo parámetro genérico TClient de la llamada de la siguiente manera.

i.e. var hubContext = GlobalHost.ConnectionManager.GetHubContext<LocationHub>();

En este caso, en el que no especifico TClient, todos los clientes javascript conectados reciben el evento de forma normal utilizando el siguiente código del lado del cliente.

var hub = $.connection.locationHub;
hub.client.locationUpdatedCallback = function (locationName) {
    console.log('Updated position',locationName);
    getUpdatedListFRomServerAndDisplay();
};

¿Es posible que al especificar los tipos T y TClient, el método esté resolviendo el contexto de concentrador incorrecto dentro del método webapi?

Como referencia, las versiones de mi paquete son las siguientes.

  <package id="Microsoft.AspNet.SignalR" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.SignalR.Core" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.SignalR.JS" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.SignalR.SystemWeb" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi" version="5.2.3" targetFramework="net45" />

Comentario más útil

Tuve un problema similar en una aplicación que estaba escribiendo y (alguien más) descubrió que le estaba contando a SignalR sobre nuestro solucionador de dependencias dos veces, una vez configurando GlobalHost.DependencyResolver y una vez pasándolo como una opción a nuestra llamada MapSignalR . La mayoría de las cosas aún funcionaban, pero la transmisión se rompió sutilmente de manera similar a cómo lo describe. En particular, obtener una referencia a HubContext desde fuera de una llamada de SignalR (como lo que estás haciendo con WebAPI) parecía darme un objeto que enviaba mensajes a un agujero negro.

Todos 3 comentarios

Tuve un problema similar en una aplicación que estaba escribiendo y (alguien más) descubrió que le estaba contando a SignalR sobre nuestro solucionador de dependencias dos veces, una vez configurando GlobalHost.DependencyResolver y una vez pasándolo como una opción a nuestra llamada MapSignalR . La mayoría de las cosas aún funcionaban, pero la transmisión se rompió sutilmente de manera similar a cómo lo describe. En particular, obtener una referencia a HubContext desde fuera de una llamada de SignalR (como lo que estás haciendo con WebAPI) parecía darme un objeto que enviaba mensajes a un agujero negro.

Este problema se ha cerrado como parte de la limpieza de problemas como se describe en https://blogs.msdn.microsoft.com/webdev/2018/09/17/the-future-of-asp-net-signalr/. Si aún tiene este problema, no dude en volver a abrir y comentar para hacérnoslo saber. Todavía estamos interesados ​​en saber de usted, la acumulación se hizo un poco grande y tuvimos que hacer una limpieza masiva para volver a estar al tanto de las cosas. ¡Gracias por sus continuos comentarios!

@IanYates gracias señor. Bajé por la madriguera del conejo durante horas antes de ver tu comentario. Eliminar eso de MapSignalR () solucionó el problema para mí.

¿Fue útil esta página
0 / 5 - 0 calificaciones