Detecteren of .NET gestart is

[Xymox]

Ik vraag mij iets af.

Ik start vanuit een Win32 zelfbouwapplicatie (via COM interop) de IBM WebSphere WMB/MQ client om berichten te versturen. De eerste aanroep duurt een stuk langer omdat de .NET omgeving eerst 'in de lucht' moet komen alvorens de client gestart wordt. Pas daarna wordt het bericht verstuurd. Op sommige systemen heb ik dit geklokt op 3-6 seconden. Het versturen (en ontvangen van het antwoord) van het bericht duurt nog geen 500 ms. Dus de overhead bij de eerste keer aanroepen is behoorlijk hoog.

Ik wil graag in een statusveld van de aanroepende applicatie aan de gebruiker mededelen dat .NET eerst gestart wordt. Ik moet dus vanuit de Win32 applicatie kunnen detecteren dat .NET nog niet loopt.

Ik heb dit uitgezocht en ik vermoed dat ik wel een oplossing heb, maar ik heb geen idee of dit de juiste methode is:

De assembly mscorlib.dll moet aanwezig zijn in een draaiende .NET omgeving en zal dus altijd aanwezig zijn

Ik roep EnumProcesses (WinAPI, KERNEL32.DLL) aan om een lijst met alle lopende processen te bepalen. In deze lijst zoek ik alle instanties van het proces dllhost.exe.
Daarna roep ik EnumProcessModules aan voor elk gevonden dllhost.exe proces en krijg daarmee een lijst met geladen modules binnen die processen.
In deze lijst zoek ik naar mscorlib.dll. Als deze aanwezig is, kan ik ervan uitgaan dat .NET draait.

Makes this sence ?
Of is er een meer simpele oplossing ?

[Gomez12]

Gewoon standaard een bericht gooien dat .net opgestart wordt als je de eerste .net library inlaad en weghalen als je eerste eigen functie gaat draaien...
Als je dit echt niet voor elkaar krijgt dan gooien simpelweg je statusveld gooien voor opstarten buiten .net om en het volgende statusbericht via een .net component gooien. Door dat component wordt .net geladen en klopt alles weer, minieme vertraging omdat je 1 extra functie aanroept maarja...

[marrik]

Volgens mij is het niet zozeer of .NET draait maar wordt er blijkbaar nog eea geladen door de runtime.
Wat is de rol van .NET hierin? Verzorgt een .NET application de communicatie naar MQ? Of is dit de server die wordt aangesproken?

[Xymox]

marrik schreef op donderdag 16 oktober 2008 @ 23:14:
Volgens mij is het niet zozeer of .NET draait maar wordt er blijkbaar nog eea geladen door de runtime.
Wat is de rol van .NET hierin? Verzorgt een .NET application de communicatie naar MQ? Of is dit de server die wordt aangesproken?

De IBM MQ client draait onder .NET (lokaal geinstalleerd op het workstation) en maakt verbinding met de WebSphere WMB servers voor de communicatie.
De overhead van het versturen van een bericht vanaf de unmanaged Win32 omgeving via MQ en weer terug is :

- Creeren van de MQ client COM
- Starten van de standaard .NET omgeving (basis assemblies)
- Starten van de MQ client zelf binnen .NET
- Versturen bericht en ontvangen van antwoord en teruggeven aan de aanroeper (via COM) naar de Win32 omgeving

Bij de eerste aanroep zullen dus alle bovenstaande acties uitgevoerd worden. Herhaalde aanroepen daarna doorlopen de 2e en 3e stap niet omdat alles al in de lucht is.
Het zou dit wellicht beter zijn om te checken of de MQ client zelf binnen .NET live is. Maar ik heb geen idee of dat te detecteren is buiten .NET.

Ik kan eens kijken of ik de geladen IBM MQ modules kan vinden in de enumeratie.

[Gomez12]

Waarom wil je trouwens dit weten / doen? Lijkt me opzich helemaal niet relevant en redelijk moeilijk ( detecteren of je MQ client gestart is ).

Kan je niet gewoon beter in je app een queue/ aparte thread maken die het verstuurt wanneer het kan? Ik ken weinig situaties waarin 1x 3-6 seconden echt kritisch is zolang het maar niet de GUI/user experience beinvloed.

Elk bericht gooi je in de queue, en na versturen geef je een status terug in je overzicht. Zolang het niet de GUI beinvloed zie ik het probleem niet echt, bij snel 100 berichten invoeren ziet iemand een vertraging bij het 1e bericht, maar daarna wel 99 berichten achter elkaar gaan... Zolang je maar niet hangt op je 1e bericht gaat het volgens mij goed...

Enumeratie etc lijkt mij persoonlijk vrij riskant, straks hangt IBM het onder een ander project en je enumeratie kan opnieuw gemaakt worden...

[sopsop]

Het hele idee van MQ is toch dat het in weze een vorm is van shoot & forget. Je schiet wat in de queue bij de ontvanger en vervolgens hou je je reply queue in de gaten of er een reply is, of een timeout oid krijgt. Het is asynchrone communicatie.

[ Voor 6% gewijzigd door sopsop op 17-10-2008 10:08 ]

[Haan]

sopsop schreef op vrijdag 17 oktober 2008 @ 10:08:
Het hele idee van MQ is toch dat het in weze een vorm is van shoot & forget. Je schiet wat in de queue bij de ontvanger en vervolgens hou je je reply queue in de gaten of er een reply is, of een timeout oid krijgt. Het is asynchrone communicatie.

Dat is opzich toch prima hier? Tenzij er natuurlijk eerst iets gedaan moet worden met de response van een voorgaand bericht, voor een nieuw bericht verstuurd kan worden.

[mulder]

Haan schreef op vrijdag 17 oktober 2008 @ 12:18:
[...]

Dat is opzich toch prima hier? Tenzij er natuurlijk eerst iets gedaan moet worden met de response van een voorgaand bericht, voor een nieuw bericht verstuurd kan worden.

Ik denk hij bedoelt dat je een bericht verstuurd zonder dat je weet op de ontvangende partij in de lucht is. Je zet het bericht op de 'out queue' en op het moment dat het ontvangende systeem in de lucht is trekt deze de queue leeg.

[Xymox]

sopsop schreef op vrijdag 17 oktober 2008 @ 10:08:
Het hele idee van MQ is toch dat het in weze een vorm is van shoot & forget. Je schiet wat in de queue bij de ontvanger en vervolgens hou je je reply queue in de gaten of er een reply is, of een timeout oid krijgt. Het is asynchrone communicatie.

Dat klopt in het geval van Fire&Forget/confirm berichten. Echter heb ik het hier over Request-Reply berichten.
Het proces (en ook de GUI) moet hier echt wachten op antwoord. De gebruiker mag/kan ondertussen niets doen. Het antwoord is cruciaal in het bepalen van het vervolg.

Kan je niet gewoon beter in je app een queue/ aparte thread maken die het verstuurt wanneer het kan? Ik ken weinig situaties waarin 1x 3-6 seconden echt kritisch is zolang het maar niet de GUI/user experience beinvloed.

Een aparte thread heeft geen zin omdat de gebruiker moet wachten op de response. Het gebruikersproces moet die stap eerst door voordat het vervolg bepaald en ingezet gaat worden.

Ik denk hij bedoelt dat je een bericht verstuurd zonder dat je weet op de ontvangende partij in de lucht is. Je zet het bericht op de 'out queue' en op het moment dat het ontvangende systeem in de lucht is trekt deze de queue leeg.

Het wel dan niet in de lucht zijn van de ontvangende partij wordt door MQ afgehandeld. Het response bericht zal evt foutmeldingen bevatten als het achterland niet up is of niet in de maximale wachttijd reageert.
Echter gaat het mij hier om de verbinding tussen de applicatie en de .NET IBM client welke ook overhead geeft.

[Meekoh]

De grap is dat .NET niet iets is dat "draait". Het zijn voornamelijk een zooi DLL's die worden gebruikt door verschillende applicaties. Waarschijnlijk is hij bij de eerste aanroep de DLL's in het geheugen aan het laden.

[urk_forever]

Waarom wil je dit specifiek alleen maken voor het geval dat .Net nog niet draait. Als iets van een status balk maakt kan je daar toch in zetten, "Vraag verzonden, wacht op antwoord" dan weet de gebruiker dat hij wachten moet. Als de eerste aanroep wat langer duurt weet de gebruiker dit, daarna zie je het eigenlijk niet eens.

Nvm dit had Gomez12 al gezegd

[ Voor 6% gewijzigd door urk_forever op 17-10-2008 15:59 ]

[SeeSharp.nl]

Welk component gebruik je om vanuit .NET een connectie te maken met WMB?
Ik heb een tijd geleden een aantal .NET componenten en services gemaakt die via 'amqmdnet.dll' connecten naar WMB. In sommige gevallen waren het fire en forget oplossingen en in andere gevallen moest ik wachten op een antwoord. (De WMB oplossing heb ik ook zelf ontwikkeld.)

Ik kan me alleen helemaal niet meer herinneren dat de eerste keer communicatie leggen lang duurde. Het initieeren van de MQQueueManager kost tijd, maar niet zolang als jij aangeeft.

Kun je a.u.b aangeven welke dll je gebruikt om vanuit .NET naar MQ te praten?

[MSalters]

Je kunt natuurlijk ook zelf een (timed) LoadLibrary("mscorlib.dll") doen. Als die al geladen is, is het snel. Zoniet, dan niet - maar dan bespaar je de MQ client de overhead van de eerste load, en kun je in de UI waarschuwen. En misschien kun je op die manier de hele workflow wel sneller krijgen, als je al eerder weet dat je de client gaat aanroepen.

[Verwijderd]

Kun je niet bij het opstarten van je applicatie een een fire&forget message sturen naar MQ?
We zijn eraan gewend dat 't opstarten van een applicatie wat tijd kost, en 3-6 seconden extra is dan geen probleem.