Livslängd session

[resq]

Hej!

 

Hur hålls en seesion vid liv. Vad gör att timeout-tiden nollställs och ger nya minuter? Eller är sessiontiden satt till x minuter oavsett aktivitet?

 

Anledningen till att jag frågar är att den session jag har för att kolla inloggningsstatus och ackreditetsnivå dör efter standard 30 minuter trots att jag aktivt jobbat med applikationen.

 

Taxam för redogörelse.

 

/ David

[Magnus Ahlkvist]

Sessionen ska inte time:a ut om den används. Om man accessar en sida som har session-state påslaget (vilket jag antar att alla sidor har om du kollar login-status) så ska timern nollställas vid varje access.

Så ditt problem är märkligt och luktar MS-bugg. Såvida du inte jobbar utan att ladda om någon sida.

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[Mr Andersson]

Ska bara tillägga att det måste vara ASP-sidor. Att hämta HTML-sidor nollställer inte session-timern.

 

[xyzz]

"luktar MS-bugg"

 

Har aldrig märkt att sessioner skulle vara buggigt, du får gärna visa en sida som beskriver den bugg du sagt att det luktar.

 

 

 

 

[resq]

 

Oki. Kanske strul med Brinkster då, där jag har provversionen av applikationen uppe...

 

Det torde alltså räcka att jag kör följande koll på varje ASP-sida:

 

if session("inloggad") = "true" and session("ack") <= 4 then

 

och sedan den kod som ligger under ackreditet.

 

Eller måste jag uppdatera sessionen på annat sätt? Sessionen skapas i en grundläggande ackreditetskollsida som sedan skickar vidare till meny etc...

 

/ David

 

 

 

[inlägget ändrat 2002-06-26 16:08:02 av resq]

[xyzz]

Kolla dina cookie inställningar, sessions är ju beroende av cookies.

 

Sen är det inte helt omöjligt att Brinkster stängt av sessionshanteringen men varför de skulle gjort det vet jag inte, borde nog stå någonstans ochså isåfall.

 

 

[Magnus Ahlkvist]

Eftersom MS gjort IIS, och beskrivningen av problemet är att trots att sessionsvariabler kollas på varje sida time:ar sessionen ut verkar det vara en IIS-bugg, alltså en MS-bugg.

Eller har du något annat förslag på vad som är fel?

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Eftersom MS gjort IIS, och beskrivningen av problemet är att trots att sessionsvariabler kollas på varje sida time:ar sessionen ut verkar det vara en IIS-bugg, alltså en MS-bugg.

 

Sådana som du kallas troll.

 

Det fnns ingen IIS bugg när det gäller sessioner, du kan ju inte sitta hitta på massa skit.

 

Eller har du något annat förslag på vad som är fel?

 

Ja, två saker, antingen har han gjort fel någonstans eller så blockeras sessions cookien på grund av inställningar.

 

Det mer troligt än att genast påstå att det finns nån sorts allmän IIS bugg när det gäller sessioner som ingen annan här någonsin hört talas om.

 

Ett tredje alternativ är att sessioner är avstängt på servern

 

[inlägget ändrat 2002-06-26 16:22:53 av xYzz]

[resq]

 

Det känns som om det är nå't strul med Brinkster på nå't sätt... För det funkar utmärkt när jag kör lokalt.

 

Det där med IIS-bugg tror jag inte på eftersom det funkar lokalt i IIS men inte på Brinkster... Jag undersöker vidare. Jag har nämligen haft strul med sessionernas livslängd och Brinkster tidigare... Det funkar nämligen att logga in och skapa menyn (som är beroende på ackreditet) och sedan plocka in och ut information. Men ibland så dör sessionen helt plötsligt, utan att jag begär det varken i applikationen eller på annat sätt.

 

Applikationen skall iaf upp på en annan server sedan, men den servern är inte inköpt än. Därav strulet med Brinkster som mellanstation...

 

Men nu vet jag iaf att jag gjort rätt.

 

/ David

 

 

 

[inlägget ändrat 2002-06-26 16:26:49 av resq]

 

-----

 

Vilken debatt det skapades av denna lilla fråga... Ibland vet man inte alltid vad man förorsakar...

 

/ David

[inlägget ändrat 2002-06-30 17:34:55 av resq]

[Magnus Ahlkvist]

Det fnns ingen IIS bugg när det gäller sessioner, du kan ju inte sitta hitta på massa skit

 

Jo, det finns en del buggar, samtliga dokumenterade av Microsoft själva. De flesta har med onTimeout-eventet att göra.

Och nej, jag hittar inte på skit, jag föreslår en möjlig orsak till varför det är fel, till skillnad från dig.

 

 

Ja, två saker, antingen har han gjort fel någonstans eller så blockeras sessions cookien på grund av inställningar.

I sådant fall skulle applikationen inte fungera alls. I det här fallet time:ar sessionen ut efter 30 minuter.

Av beskrivningen av problemet att döma har han heller inte gjort något fel, eftersom han på varje sida kollar om en sessions-variabel är satt eller inte, konstaterar att den är satt, och därmed vet vi två saker:

1. Session-state är påslaget

2. Sessionens timer SKA nollställas

 

Ett tredje alternativ är att sessioner är avstängt på servern

Det är inte troligt, av samma orsak som ovan.

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Jo, det finns en del buggar, samtliga dokumenterade av Microsoft själva. De flesta har med onTimeout-eventet att göra.

 

Vad svamlar du om ? Det var ju det jag frågande, visa mig en sida där det står att IIS ( och då menar jag inte IIS4 eller nåt annat gammalt crap ) har en bugg som gör att sessioner timar ut oavsett inställningar ?!

 

Och nej, jag hittar inte på skit, jag föreslår en möjlig orsak till varför det är fel, till skillnad från dig.

 

Till skillad från mig ? Du är lustig du, du påstår genast att det är nån sorts ospecad IIS bugg medans jag säger precis vilka orsaker det kan vara.

 

I sådant fall skulle applikationen inte fungera alls. I det här fallet time:ar sessionen ut efter 30 minuter.

 

Till skillnad från dig tror jag inte ordagrant på inläggen, kunde ju mycket väl vara något fel i hans script som han sedan beskriver på ett felaktigt sätt eller hur ?

 

Jag sa precis som det kan vara medans du refererar till någon ospecad bugg, på vilket sätt hjälper det ?

 

 

[Magnus Ahlkvist]

Till skillnad från dig tror jag inte ordagrant på inläggen, kunde ju mycket väl vara något fel i hans script som han sedan beskriver på ett felaktigt sätt eller hur ?

Jag tänker inte sitta och anta att det någon skriver om sina förutsättningar är fel. Att först gissa vad någon har skrivit fel, och sen lösa ett problem utifrån påhittade förutsättningar är inte till någon större hjälp för någon.

 

Jag sa precis som det kan vara medans du refererar till någon ospecad bugg, på vilket sätt hjälper det ?

Utifrån de förutsättningar han postade är det troligt, eller till och med mycket troligt, att felet ligger i IIS-servern och inte i asp-applikationen. Du sa verkligen inte precis som det kan vara, eftersom du postade två förslag som var direkt felaktiga - det ena att cookie-hanteringen inte var påslagen i browsern, det andra att session-hanteringen var avslagen på servern.

 

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Du sa verkligen inte precis som det kan vara, eftersom du postade två förslag som var direkt felaktiga - det ena att cookie-hanteringen inte var påslagen i browsern, det andra att session-hanteringen var avslagen på servern.

 

På vilket sätt var de felaktiga ?? Man kan ju inte sitta och förutsätta att allt i ett inlägg är korrekt beskrivet, det är ju urdumt, man får ju tala om hur saker funkar och sedan vad som kan vara fel vilket var det jag gjorde.

 

DU däremot hänvisade till något totalt felaktigt som du fortfarande inte bevisat med någon länk.

 

Varför inte bara erkänna att det du sa var fel istället för att fortsätta rappakaljan ?

 

"Luktar MS bugg" var det ditt hjälpsamma inlägg du hänvisade till förrut ??

 

Jag har fortfarande inte sett länken du refererar till om sessions buggen du påstår finns. Som MS hade verifierat dessutom påstod du ?

 

 

[Magnus Ahlkvist]

DU däremot hänvisade till något totalt felaktigt som du fortfarande inte bevisat med någon länk.

Jag sa att det kunde vara en MS-bugg. Vilket fortfarande är mycket möjligt.

 

Varför inte bara erkänna att det du sa var fel istället för att fortsätta rappakaljan ?

Det är möjligt att det jag skrev var fel, jag har aldrig påstått att jag är säker på att jag har rätt. Däremot är jag helt säker på att sessions-hantering på servern är påslaget, eftersom det annars inte skulle vara möjligt att logga in i applikationen, samt att browsern accepterar cookies, av samma anledning.

Och nej, jag tänker inte påstå att den som postade inlägget inte vet att han egentligen inte kan logga in, utan istället påstår att sessionen time:ar ut efter en halvtimme.

 

"Luktar MS bugg" var det ditt hjälpsamma inlägg du hänvisade till förrut ??

Jag har fortfarande inte sett länken du refererar till om sessions buggen du påstår finns. Som MS hade verifierat dessutom påstod du ?

Jag har sagt att MS verifierat en hel del buggar med sin sessions-hantering i IIS. De flesta avhjälpta med någon patch eller service-pack, andra inte. Session_OnTimeout är inte avhjälpt - att den körs ibland, ibland inte.

Några buggar är sannolikt inte funna, och därför inte avhjälpta. Microsoft skriver mycket kod, och med mycket kod blir det mycket buggar. Oavsett hur bra kvalitetssäkringssystem man har.

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Jag sa att det kunde vara en MS-bugg. Vilket fortfarande är mycket möjligt.

 

Hehe, ja som ingen annan upptäckt som använder IIS då ?

 

Tror nog mina förklaringar låg närmare sanningen men vill man tolka något 100% ordagrant ja då finns det ju inget utrymme för någon annan förklaring vilket var ditt syfte tydligen.

 

Själv har jag då aldrig haft några problem med sessioner, i de allra flesta fall är det nog den som scriptar som gör felet men det är ju alltid bekvämt att kunna skylla på att det "luktar MS bugg" när något går fel.

 

[inlägget ändrat 2002-06-26 19:39:10 av xYzz]

[Magnus Ahlkvist]

Hehe, ja som ingen annan upptäckt som använder IIS då ?

 

Hur tror du buggar upptäcks? Varför tror du att det med jämna mellanrum kommer ut patchar till IIS? För att den är felfri? Felen uppdagas undan för undan, inte alla på en gång. Det finns inget som talar för att IIS nu efter alla patchar är helt felfri.

 

Tror nog mina förklaringar låg närmare sanningen men vill man tolka något 100% ordagrant

 

Det behöver man inte göra. Det räcker att man tror att den som postar vet om han kan logga in eller inte i sin applikation för att avgöra att dina förslag var fel.

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Hur tror du buggar upptäcks? Varför tror du att det med jämna mellanrum kommer ut patchar till IIS? För att den är felfri? Felen uppdagas undan för undan, inte alla på en gång. Det finns inget som talar för att IIS nu efter alla patchar är helt felfri.

 

Men snälla nån, du tycks tro att Sessioner är något som sällan används ??

 

Fanns det en sådan bugg skulle den upptäckts i samma ögonblick den specifika IIS versionen släpptes.

 

Slut från mig, dina inlägg platsar bättre i datorkrig.

 

[inlägget ändrat 2002-06-26 19:47:56 av xYzz]

[Magnus Ahlkvist]

Fanns det en sådan bugg skulle den upptäckts i samma ögonblick den specifika IIS versionen släpptes.

Det här gäller för alla buggar som har funnits i IIS, eller vilken annan programvara som helst för den delen. Men det fiffiga är att buggar inte uppträder under normala förhållanden, i så fall skulle de aldrig ha passerat testfasen.

 

Slut från mig, dina inlägg platsar bättre i datorkrig.

Vad menar du med det? Att anta att ett fel kan bero på en bugg i en programvara platsar knappast som datorkrig. Det finns ingen felfri kod. Jag jobbar 100% med Microsoft-produkter, och är ganska nöjd, och har vant mig vid "workarounds" för att de vid sällsynta tillfällen inte beter sig enligt dokumentationen. Jag är ett stort fan av MS utvecklingsmiljöer. IIS kanske de borde lagt lite mer krut på innan de släppte senaste releasen, men å andra sidan är MS snabba med patchar så snart fel upptäcks.

Världen är inte svart eller vit. Microsoft är inte satan eller jesus. De är som vilket annat mjukvaruföretag som helst - de släpper undermåliga program för att hinna med releaserna, och väljer att släppa service-packs och patchar efter releaserna istället.

Det här har ingenting med MS specifikt att göra, vilket du försöker påstå att jag menar.

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Du kunde inte släppa det eller ?

 

Vi pratade om sessioner, det finns ingen känd bugg där i nuvarande IIS vilket var vad du påstod.

 

Detta var ingen allmän diskussion om buggar utan att du gav det väldigt hjälpfulla "det luktar MS bugg" utan att backa upp det med något.

 

Som sagt, tycker sådana inlägg liksom det senaste du nu presterade där du säger att MS medvetet släpper icke färdiga program passar bättre under datorkrig.

 

Men du kanske har något att backa upp det påståendet med ochså ? Väntar fortfarande på din sessions bugg länk.

 

Kan du släppa tråden nu eller ska vi forsätta i datorkrig därför att det verkar ju på dina inlägg som att det egentligen är det du vill.

 

[inlägget ändrat 2002-06-27 00:48:07 av xYzz]

[Magnus Ahlkvist]

Det finns dokumenterade buggar i sessions-hanteringen - den kändaste att session_OnTimeout inte triggas varje gång sessionerna time:ar ut.

Diskussionen behöver inte föras i datorkrig.

 

MS släpper naturligtvis program som de vet är inte 100% testade. Liksom alla andra mjukvaruföretag. (märk att jag inte på något sätt anklagar Microsoft för något annat än att vara lika goda kålsupare som resten av branschen) Det här är ingen hemlighet, utan något som Mike Iam (produktchef för VB.NET, tidigare produktchef för mobile-SDK:t till VB om jag inte minns helt fel) talade på senaste VSLive-konferensen om att Microsoft försöker bli bättre på, men att det fortfarande i en del produktserier är på det viset. .NET-miljöerna är ett område där MS har satsat hårt på att ta bort halvdana program ifrån releaserna, och släpper dem istället senare som gratis-plugins.

Iam pratade om "det gamla microsoft" och "det nya microsoft". Med "det gamla microsoft" menade han releaser som kom innan .NET-satsningen tog fart - det microsoft som hellre släppt program i tid än att släppa helt testade system.

 

Till mitt uttalande "det luktar MS bugg" - det är fortfarande mest troligt att felet ligger i IIS-servern, utifrån de postade förutsättningarna.

Om det beror på att Brinkster är odugliga eller att IIS-servern inte är designad för att hosta så många applikationer som Brinkster sannolikt har i sina server-installationer kan man ju diskutera.

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Det finns dokumenterade buggar i sessions-hanteringen - den kändaste att session_OnTimeout inte triggas varje gång sessionerna time:ar ut.

Diskussionen behöver inte föras i datorkrig.

 

Vad jag vet existerar ingen session_ontimeout, däremot finns en session_onend, så du vet ju inte ens vad du babblar om och ändå fortsätter du.

 

Och vart är länken som säger detta ?

 

Om det beror på att Brinkster är odugliga eller att IIS-servern inte är designad för att hosta så många applikationer som Brinkster sannolikt har i sina server-installationer kan man ju diskutera.

 

Och det platsar inte för datorkrig eller ?

 

Hittils i tråden har du:

 

- påstått att IIS har en verifierad bugg som gör att sessioner timar ut oavsett inställningar och oavsett om man laddar om en sida under sessionen.

- Microsoft släpper MEDVETET ofärdiga produkter.

- IIS är inte designad för att hosta många applikationer.

 

Och det platsar inte under datorkrig eller ? Ja det platsar garanterat inte här iallfall !

 

[inlägget ändrat 2002-06-27 11:15:10 av xYzz]

[Magnus Ahlkvist]

Vad jag vet existerar ingen session_ontimeout, däremot finns en session_onend, så du vet ju inte ens vad du babblar om och ändå fortsätter du.

Eftersom jag inte längre använder den inbyggda sessionshanteringen av prestandaskäl och för att det inte funkar i kluster är det inte så konstigt att jag har tagit fel på event-namnet.

 

Och vart är länken som säger detta ?

Hittar inte länken just nu, men problemet beskrivs som följer:

Om Session_OnEnd försöker skapa ett connection-objekt till en databas som existerar på en annan server än webb-servern kommer det ibland att fungera, ibland inte. Anledningen är att Session_OnEnd körs med en annan security-context än asp-sidorna, och därför funkar inte ex.vis CreateFile (som används för att ansluta till en named pipe). Buggen i det hela är att det ibland fungerar, ibland inte.

 

påstått att IIS har en verifierad bugg som gör att sessioner timar ut oavsett inställningar.

Nej, jag har skrivit att MS har verifierat buggar i IIS:s sessionshantering.

 

 

Microsoft släpper MEDVETET ofärdiga produkter.

Vilket verifierats av Mike Iam

 

IIS är inte designad för att hosta många applikationer.

Om man väljer att inte köra en webb-sajt i sin egen server-process riskerar man att stoppa ALLA sajter som körs i IIS:s egen process om en sida på sajten hamnar i en loop som käkar minne. (vilket inte alls är ovanligt på ett webhotell som är gratis, eftersom nybörjare lär sig asp på såna ställen).

Om man istället låter alla sajter köra i sin egen server-process skapas många processer i Windows, vilket gör att schemaläggaren kommer att slå bakut. NT-kärnan schemalägger bara de X processerna med högst prioritet som är körklara (om jag minns rätt från OS-kurserna är det 15 för NT4 och något högre för W2k). Det beror på att schemaläggaren annars skulle ta för mycket processortid, vilket skulle resultera i att ingen process skulle få köra överhuvudtaget.

Jag har jobbat hos en ISP som hostar uppemot 300 sajter på samma serverinstallation, och det är långt ifrån problemfritt, trots att de tekniker som jobbade där hade +5 års erfarenhet av att jobba bara med IIS-administration.

 

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.

 

[xyzz]

Dina inlägg fortsätter i datorkrigs stil.

 

Hittar inte länken just nu, men problemet beskrivs som följer:

Om Session_OnEnd försöker skapa ett connection-objekt till en databas som existerar på en annan server än webb-servern kommer det ibland att fungera, ibland inte. Anledningen är att Session_OnEnd körs med en annan security-context än asp-sidorna, och därför funkar inte ex.vis CreateFile (som används för att ansluta till en named pipe). Buggen i det hela är att det ibland fungerar, ibland inte.

 

Jag vet, men det hade ju inget med ditt påstående att göra.

 

Detta har ju bara att göra med under vilket context processen körs under.

 

Tveksamt om det ens ska klassas som en bugg men det kan man diskutera.

 

Det existerar fortfarande ingen sådan bugg som du beskrev.

 

 

[Johan A.]

Du menar kanske:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q243828

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q247968

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q277329

Fast de är ju ganska gamla...

 

 

 

[Magnus Ahlkvist]

Dina inlägg fortsätter i datorkrigs stil

Att förklara hur och varför ett problem uppstår är datorkrig??

 

Det existerar fortfarande ingen sådan bugg som du beskrev.

 

Men snälla du, jag förklarade att problemet kan vara en bugg i IIS. Det liksom andra orsaker till problemet är möjliga.

Jag har inte beskrivit någon bugg som inte finns, bara sagt att det är möjligt att det finns en bugg som inte är känd.

Att jag inte utesluter buggar tolkar du som att jag baktalar MS - men säg ett enda företag som har släppt buggfria program?

 

--

En röst talade till mig och sade:

"Le och var glad, ty det kunde vara värre".

Så jag log, och jag var glad.

Och det blev värre.