none
vb.Net Module im IIS

    Allgemeine Diskussion

  • Hallo

    Wenn in vb.net auf IIS ein Module genutzt wird, sind die Variablen etc. ja für alle Request verfügbar. Über Funktionen werden diesem Modul gewisse Threads/Request welche in den Schlafmodus gelegt wurden zugewiesen und bei gewissen Events werden dann die nötigen Threads wieder geweckt. In welchem IIS-Bereich ist dieses Modul verfügbar? Ist das pro ApplicationPool, pro Web, pro virt. Verzeichnis?

    Besten Dank

    Gruss Christoph

    • Typ geändert chmav Samstag, 26. Januar 2013 14:31
    Samstag, 19. Januar 2013 09:53

Alle Antworten

  • Standardmässig sollte das per ApplicationPool sein. Allerdings solltest du keinerlei Module verwenden, es sei denn du hast echte statische Klassen.
    Samstag, 19. Januar 2013 10:21
  • Hallo Stefan

    Was wäre die Alternative, damit gewisse Request/Threads schlafen gelegt werden können und dann von einem anderen Request aus aufgeweckt werden?

    Mit diesem Ansatz funktioniert es, jetzt wollte ich einfach sicher gehen, was passiert, wenn mehrere Anwendungen im gleichen AppPool laufen.

    Gruss Christoph

    Samstag, 19. Januar 2013 10:39
  • Hier kommt es auf die umzusetzenden Anforderungen an. Was läuft in diesen Thread? Wie hängen diese an den Requests?
    Samstag, 19. Januar 2013 10:49
  • Per JavaScript wird im Browser ein Aufruf auf diese Seite gemacht. Sobald ein Event eintrifft, soll der Client eine Info anzeigen können. Daher wird der Request auf dem IIS schlafen gelegt und wenn ein solcher Event eintritt, wird bestimmt, welcher Request wieder geweckt werden soll und bekommt dann als Response Infos zum Event. Nach 30 Sekunden wird der Request automatisch geweckt und bekommt die Meldung, dass nichts passiert ist. Dann wird gleich wieder der nächste Request gemacht. So können die Events schnell am Client angezeigt werden.

    Im Thread selber läuft also kaum etwas, nach dem aufwecken holt er sich die Meldung aus der DB und ist fertig.

    Gruss Christoph

    Samstag, 19. Januar 2013 11:06
  • Schau mal, ob RX eine Möglichkeit für dich darstellt, hier gibt's auch die nötigen JavaScript-Komponenten. Ansonsten sieht es wie Long Polling, respektive HTML5 WebSockets aus.
    Samstag, 19. Januar 2013 11:50
  • Werde ich prüfen.

    WebSockets wären sehr interessant, wenn der Internet Explorer das schon in V8 oder sicher 9 unterstützen würde. Unsere SW läuft meistens auf IE und darum muss es vorallem da gehen.

    Gruss Christoph

    Samstag, 19. Januar 2013 12:08
  • Hallo Christoph,

    ich weiß nicht, was genau Du da machen willst. IIS und/oder ASP.NET sind nicht dafür gedacht, Threads in irgendeinem halbgaren Zustand "auf Halde" zu legen und bei Bedarf dann zu aktivieren.

    Ein Request kann nicht einfach so "geweckt" werden (was auch immer Du darunter verstehst).

    Ein Push ist, mit Ausnahme moderner Sachen wie Websockets, über IIS/ASP.NET/http nicht möglich. Es gibt also keine Möglichkeit, den Client proaktiv über Veränderungen zu informieren, wenn der Client nicht von sich aus eine Anfrage an den Server stellt.

    Wenn Du eine eigene Serveranwendung erstellst und darüber eine dauerhafte Verbindung mit dem Client aufrecht erhältst, geht das natürlich. Aber dann kann der Browser nicht der Client sein, es sei denn, man würde ein ActiveX, Flash, Silverlight Control nutzen.

    Allerdings würde mich interessieren, was genau Du da eigentlich machen willst. Beschreib doch mal im Detail mit passenden Beispielen, wie sowas aussehen soll.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 19. Januar 2013 19:56
  • Hallo Stefan

    Ich nutze dazu AutoResetEvent. Das Objekt wird über eine Funktion vom Modul mit dem Benutzernamen zusammen einem Dictionary hinzugefügt und mit WaitOne für 30 Sekunden ein Warten ausgelöst.
    Wenn jetzt einem User die Meldung an den Client gesendet werden soll, wird das AutoResetEvent-Objekt zu diesem User aus dem Dictionary geholt und wieder gestartet. Dann wird noch aus der Datenbank die Meldung geladen und der Request erhält die Meldung und kann per JS-Meldung den User informieren.
    Für die IE ist es einfach ein langer dauernder Request.

    Vor Jahren hatte ich das über ein ActiveX gemacht und habe dann den Tipp mit diesen Blockierenden Requests erhalten und das funktioniert so auch. Jetzt hatte ich mir eben gefragt, wie es mit dem Speicher vom Modul aussieht, ob da für weitere Webanwendungen ein seperater AppPool gewählt werden sollte.

    Als Beispiel für diese Funktion: Eine Webseite(Business-Software, also nicht für jeden User irgendwo im Internet) soll den einzelnen Usern gleich eine Meldung anzeigen, wenn über Tapi ein Telefonanruf empfangen wird. Ein solcher Empfang wird über einen Webservice an den IIS gemeldet. Da wird bestimmt, welche(n) User das betrifft, gibt den blockierten Request frei und der User sieht so gleich, wer ihn anruft.
    Da ist natürlich ein Polling von 10 Sekunden schon zu spät. Sobald Websockets vorausgesetzt werden kann, werde ich das näher prüfen.

    Gruss Christoph

    Samstag, 19. Januar 2013 20:21
  • Hallo Christoph,

    Ein solcher Empfang wird über einen Webservice an den IIS gemeldet. Da wird bestimmt, welche(n) User das betrifft, gibt den blockierten Request frei und der User sieht so gleich, wer ihn anruft.
    Da ist natürlich ein Polling von 10 Sekunden schon zu spät.

    Das mag sein, einen anderen Weg gibt es hier aber nicht. Wenn der Server die Verbindung nicht von sich aus zumacht, macht es der Client nach einer gewissen Zeit. Da kannst Du zwar versuche, mit Connection: Keep-Alive die Verbindung offen zu halten, das wird aber in den seltensten Fällen auch wirklich funktionieren.

    ASP.NET und IIS sind hier nicht die richtigen Mittel.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 19. Januar 2013 20:43
  • Hallo Christoph,

    ist das Thema für dich abgeschlossen?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 26. Januar 2013 14:18
  • Hallo Stefan

    Zu deiner letzten Antwort: Darum wird am Client(Browser) ja gleich auch wieder eine neue Verbindung auf den Server aufgemacht, wenn der Server die Verbindung entweder während dem Warten beantwortet oder nach dem Timeout von 30 Sekunden mit einem NOP zurückgiebt.

    Bis jetzt war halt das Ziel, möglichst alles über den IIS zu machen. Muss mir da jetzt überlegen, ob es machbar ist(mit welchem Aufwand) für die ganze Kommunikation von Browser zu Server zu Tapi-Client einen eigenen Server mit Clients zu nutzen.

    Frage Ist erstmals abgeschlossen.

    Besten Dank

    Gruss Christoph

    Samstag, 26. Januar 2013 14:27
  • Hallo Christoph,

    vielen Dank für die schnelle Rückmeldung.

    Die "Anwort" selbst war ja dann nicht dabei, ändere den Threadtyp dann doch einfach auf "Diskussion", dann steht er nicht mehr als "offen" in der Liste.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 26. Januar 2013 14:29
  • Hallo

    Hätte dazu doch noch etwas. Die Empfehlung war, vom Client(Browser) aus nicht auf den IIS per JavaScript einen Request zu machen und diesen dann warten zu legen sondern über einen eigenen Mini-Server, welcher die Verbindung offen behält. Wie kann ich aus JavaScript her einen solchen einen Mini-Server aufrufen, wenn ich im Mini-Server kein http umsetzen möchte sondern ein einfacher Websocket für die Übertragung von reinen Daten/XML machen möchte? Vom IIS aus auf den Tapi-Client(Windows-Dienst mit integriertem Mini-Server) mache ich schon eine Übertragung mit XML-Daten, da ist aber .NET im Einsatz.

    Für diese Aufrufe vom Browser auf sollte keine seperate Installation von einem Programm nötig sein sondern da wirklich alles aus dem Browser(Internet Explorer) geschehen.

    Gruss Christoph

    Sonntag, 27. Januar 2013 09:44