Ügyfél újracsatlakozása

Biztosan folyamatosan újracsatlakoztathatja.

Kezelje a megszakadt eseményt az ügyfélen, és hívja fel a connect.start:

$.connection.hub.disconnected(function() {
   setTimeout(function() {
       $.connection.hub.start();
   }, 5000); // Re-start connection after 5 seconds
});

Az egyetlen probléma, amit ez okozhat, az az, hogy potenciálisan végtelen számú kérést indíthat el egy olyan kiszolgálóhoz, amely nem áll rendelkezésre az ügyfélgépekhez. Ez még problémásabbá válik, ha bevezeti a helyzetbe a mobilpiacot (őrülten lemeríti az akkumulátort).

Amikor újracsatlakozás közben megpróbál hívni egy hub metódust, a SignalR megpróbálja elküldeni a parancsot. Mivel 2 csatorna van, egy az adatok fogadására és egy a küldésre, (minden szállításhoz, kivéve a webes socketeket), bizonyos esetekben továbbra is lehetséges a kérések küldése offline állapotban. Ezért a SignalR nem tudja, hogy egy kérés sikertelen-e, amíg a böngésző nem közli vele, hogy nem tudta sikeresen végrehajtani a kérést.

Remélem ez segít!

Lehet, hogy van egy tippem... A Web.config megérintésével egy appPool Recycle jön létre, ami azt jelenti, hogy új munkafolyamat jön létre az új kérésekhez, miközben a meglévő folyamat egy ideig folytatódik, amíg a fennmaradó kérések véget érnek vagy el nem érik az időtúllépést. Azok a kérések, amelyek nem érnek véget az időtúllépési időszakban, megszűnnek.

A Signalr kliens újracsatlakozik az új folyamathoz, miközben a régóta futó feladat a régi folyamatban fut, így ha a régóta futó feladaton

GlobalHost.ConnectionManager.GetHubContext<ForceHub>();

valójában kap egy hivatkozást a "régi" hubhoz, miközben az ügyfél csatlakozik az "új" hubhoz. Ez az oka annak, hogy a Wasp által előre elkészített teszt működött: új kérést intézett közzétételre a signalr hubon, amelyet az újonnan létrehozott worker folyamatban dolgoztak fel.

Megpróbálhat konfigurálni egy singalr hátlapot (https://www.asp.net/signalr/overview/performance/scaleout-in-signalr), nagyon könnyű konfigurálni az Sql Server használatával (https://www.asp.net/signalr/overview/performance/scaleout-with-sql-server). A hátlapnak képesnek kell lennie a két munkafolyamat összekapcsolására, és remélhetőleg megkapja az értesítést az ügyfélen.

Ha ez a probléma, az új kérések által generált értesítések még a hátlap nélkül is működni fognak. Vegyük észre, hogy a hátlap valódi célja a jeladó méretezése, vagyis egy webszerver-farm összekapcsolása közöttük.

Ne feledje azt is, hogy az IIS-en belüli, hosszan futó feladatok futtatása ugyanolyan nehéz feladat, mint ahogy többek között az IIS rendszeresen újrahasznosítja az appPool-t, és időtúllépési korlátokkal rendelkezik a végrehajtásra vonatkozó kérésekre. Azt javaslom, hogy olvassa el a következő bejegyzést: http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx „Ha úgy gondolja, hogy maga is meg tud írni egy háttérfeladatot, akkor valószínűleg rosszul fogja. Nem vitatom a képességeidet, csak azt mondom, hogy finom. Ráadásul miért kellene?”

Remélem ez segít