.NET Web Services kunnen niet tegen koetjes?

[Verwijderd]

Vaag probleem op m'n werk vandaag:
Een IIS / .NET web service plus bijbehorende client applicatie (in ASP.NET) overgezet van een ontwikkelmachine naar een webserver, en dat ding was maar niet aan de praat te krijgen.
Rechtstreeks de web service aanspreken ging wel, maar vanuit de client applicatie gaf 'ie alleen maar timeout meldingen. De laatste .NET framework (opnieuw) geinstalleerd, alle settings nog 's goed nagelopen, maar 't mocht niet baten.

Wat bleek nu: op die server draait al sinds tijden en probleemloos een UD-client (THINK), en dat was de boosdoener! UD uit, en de boel draait weer als een zonnetje...

Ik kwam op die tip bij 't googlen naar een oplossing, en in 1 van de newsgroups kwam ik tegen: "switch off SETI". Het ziet er dus naar uit dat het probleem bij meerdere (alle?) koetjes voor zal komen.

Is iemand anders dit probleem ook tegengekomen? En zo ja, heeft iemand een oplossing gevonden? (behalve koe uitzetten of geen .NET web services gebruiken)

[ Voor 3% gewijzigd door Verwijderd op 17-02-2003 19:34 ]

[Verwijderd]

heeft het niks te maken met cpu time ? kun je de client niet op lage prio zetten ?

[Verwijderd]

De priority staat standaard al op 'Low', en lager kun je vanuit de GUI van Windows niet instellen.
En helaas kent Win2K Server niet zoiets als 'nice'...

[Rob]

Het is ook niet zo verstandig om koetjes en dergelijke te draaien op productiemachines.

[Jeldert]

-Rob- schreef op 17 February 2003 @ 20:03:
Het is ook niet zo verstandig om koetjes en dergelijke te draaien op productiemachines.

Beetje stresstesten moet kunnen
Deed elk bedrijf dit maar een paar weken voor DPC

[Verwijderd]

Het is ook niet zo verstandig om koetjes en dergelijke te draaien op productiemachines.

't Is ook niet echt een productiemachine, maar "de" webserver van de afdeling ontwikkeling. Hij staat geen belangrijke sites te hosten of zo.

Maar in principe doet dat er niet zo toe. Ik heb die koe op meerdere servers en werkstations draaien (allemaal met toestemming), en tot nu toe zonder problemen. Voor die servers hebben we wel eerst een paar maand gemonitord of de UD-client de performance en/of stabiliteit in de weg zou kunnen zitten, en dat was niet het geval.
Geen reden dus om die client niet te laten draaien, zelfs al is 't een productiemachine.

[ Voor 4% gewijzigd door Verwijderd op 17-02-2003 20:19 ]

[teig_r]

Ik heb een soortgelijk probleem gehad, een applicatie bleef continu access violations geven op een server, maar op de test/ontwikkelomgeving geen problemen. Kwam dus door muon. Mijn conclusie was: op zoveel mogelijk plaatsen de prioriteit laag zetten (zowel in een hostende applicatie zoals bijvoorbeeld FireDaemon) als in Windows zelf.

Zie ook mijn post op het muon forum

[Marcelloz]

klopt. Ik heb dit probleem ook gehad. Het kostte me 1,5 dag om uit te vogelen dat het inderdaad aan genome@home lag. Errug vaag. En ik kwam inderaad ook uit op dat ENE linkie. En het enige dat helpt is dat ding uit je processen gooien. Ik heb er nog net geen grijze haren aan over gehouden.

Devies is op een W2K machine met .Net-webservices geen laten grazen.

Is wel een minpuntje voor microsoft uiteraard . Stel je voor dat je een lekkere drukke server hebt, die webservice komt dus echt op de allerlaatste plaats, als er nog een kleine timeslice over is. Nou, een koe die graast wel door en geeft die webservice gewoon een kick! Hopelijk hebben ze het opgelost met .Net versie 1.1, dan kan ik 's-nacht de koe weer laten grazen op de webserver

( oja, hetzelfde probleem heb je als je geen root certificaat hebt geinstalleerd voor je https webservice, maar da's een heel ander probleem. Wel leuk om aan een hosting partij te vragen overigens, reactie is nog leuker )

[ Voor 14% gewijzigd door Marcelloz op 17-02-2003 21:14 ]

[Aike]

Met de D.net RC5 client heb ik ook heel wat win98 installaties onbruikbaar gemaakt. Regelmatig netwerk en modemproblemen na installatie van koetje. Was best jammer. Toch kan ik het niet laten om op allerlei belangrijke bakken iets voor de DPC te doen

[Bud_s]

-Rob- schreef op 17 februari 2003 @ 20:03:
Het is ook niet zo verstandig om koetjes en dergelijke te draaien op productiemachines.

Je moet natuurlijk wel prioriteiten stellen.

Top Prio : GRAZEN !!!

[ Voor 1% gewijzigd door Bud_s op 17-02-2003 21:40 . Reden: Typo ]

[stappel_]

en nooit een 2.8 of hogere versie van de d.net koe op een novell server zetten. dat zuigt zo erg dat je geen login sessies meer heb en arcserv werkt ook niet. de oude (v2.7-) versies deden het prima. echter zijn die alleen rc5-64 (geen eens ogr)

[Verwijderd]

Marcelloz schreef op 17 February 2003 @ 21:11:
klopt. Ik heb dit probleem ook gehad. Het kostte me 1,5 dag om uit te vogelen dat het inderdaad aan genome@home lag. Errug vaag. En ik kwam inderaad ook uit op dat ENE linkie. En het enige dat helpt is dat ding uit je processen gooien.

Grmpfh!
Als je dat meemaakt, gooi 't dan op 't forum! Had mij een uurtje of 4 knutselen bespaard. Wanneer de search van Parse zou werken, tenminste...

[Bergen]

Verwijderd schreef op 17 February 2003 @ 22:55:
[...]

Grmpfh!
Als je dat meemaakt, gooi 't dan op 't forum! Had mij een uurtje of 4 knutselen bespaard. Wanneer de search van Parse zou werken, tenminste...

Tja, jij had 't hier ook ff kunnen vragen

[Marcelloz]

Verwijderd schreef op 17 February 2003 @ 22:55:
[...]

Grmpfh!
Als je dat meemaakt, gooi 't dan op 't forum! Had mij een uurtje of 4 knutselen bespaard. Wanneer de search van Parse zou werken, tenminste...

je hebt er in ieder geval minder lang dan mij over gedaan waarvoor hulde!

[mookie]

Ik draai ecc2 op een servertje thuis en zodra die een dag of wat draait werkt de DNS name resolver niet meer .
Ik kan dan wel b.v. het ip van tweakers pingen maar niet naar www.tweakers.net
Heb hem als service draaien.
Als ik hem ff stop en weer start werkt de resolver weer.
Uiteindelijk maar een batch file gebouwd met net stop en net start en die draait via de scheduler elke 12 uur.

Kon ik ook niets over terug vinden.
(heb niet superhard gezocht )