RE: Session problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



By the way... I remember there were to ways of installing PHP over IIS. One
was adding it for ALL websites and the other way was adding it on a site by
site basis. I'd recommend doing the second method.
Notice that this has nothing to do with ISAPI vs CGI, it is just an option
in IIS settings (again, I've not seen a Windows 2003 Server since about two
years ago, so I don't remember where or how this was accomplished).

Rob
(excuse me for top posting, but this is just a side note)

> -----Original Message-----
> From: Andrés Robinet [mailto:agrobinet@xxxxxxxxxxxxx]
> Sent: Wednesday, November 21, 2007 5:51 PM
> To: php-general@xxxxxxxxxxxxx
> Subject: RE:  Session problem
> 
> > -----Original Message-----
> > From: Philip Thompson [mailto:philthathril@xxxxxxxxx]
> > Sent: Wednesday, November 21, 2007 4:43 PM
> > To: php-general@xxxxxxxxxxxxx
> > Subject: Re:  Session problem
> >
> > On Nov 21, 2007 11:08 AM, Mathieu Dumoulin <mdumoulin@groupe-
> cdgi.com>
> > wrote:
> >
> > > I got a strange problem here, here are the setup details first as
> > this
> > > seems
> > > to be a server problem more than a php problem but it is still
> > related to
> > > php configuration:
> > >
> > > Server: Win2003 (latest)
> > > WebServer: IIS6 (latest)
> > > PHP: php5.2.2.1
> > > MySQL: mysql.5
> > >
> > > Sites installed in server that may have influence:
> > >
> > > www.palliscience.com
> > > dev.palliscience.com
> > > maj.palliscience.com
> > > dev2.palliscience.com
> > >
> > > (All sites are installed using php5_ISAPI.dll)
> > >
> > > Problem:
> > >
> > > When i try to start a session in maj.palliscience.com (Same code as
> > > everywhere else except the content may differ), the server hangs. I
> > tried
> > > for two days to find and make sure where this server hang was
> coming
> > from
> > > and eventually came to the solid conclusion that my server hang on
> > > session_start. I tried to add different commands such as
> > > session_write_close
> > > at end of my scripts and checked that my sessions where not already
> > open
> > > by
> > > using session_id.
> > >
> > > The only way i was able to make my sessions work in
> > maj.palliscience.comis
> > > using the CGI version of PHP, but hell this is causing me problems
> i
> > never
> > > thought it would. I'm having problems with headers, and also the
> > $_SERVER
> > > variable is deadly different.
> > >
> > > So my question is simple, what could cause this problem.
> >
> >
> > Windoze and IIS. =/
> >
> >
> > > Could it be a clash in the filenames for the session files?
> >
> >
> > Yes, AFAIK, the session names will clash. Meaning, for each DNS
> > (subdomain,
> > whatever it is), use a different prefix to avoid clashes:
> >
> > $_SESSION['www'][...]
> > $_SESSION['dev'][...]
> > $_SESSION['maj']...]
> > etc.
> >
> > Obviously if some are in production, this is not a trivial change.
> >
> >
> >
> > > I tried reading a bit the php.ini
> > > and saw there is a way to split the session files in different
> > folders but
> > > i
> > > don't have the expertise nor the famous script the php.ini is
> talking
> > > about
> > > in the session section to fix or alter this info correctly. (I
> can't
> > start
> > > tweaking this, there are other sites on the machine that are in
> > production
> > > mode so i need a final configuration that will work on the first
> try)
> > >
> > > Keep in mind:
> > >
> > > 1) I got 3 other sites that sport the same code, only slightly
> > different
> > > content
> > > 2) All the sessions in the other sites work marvelously in ISAPI
> > > 3) Only maj is affected, i tried copying the code to
> > dev2.palliscience.com
> > > ,
> > > problem doesn't show.
> > > 4) I can definitely say my sessions are problematic, i comment out
> > any
> > > session_start, and the problem nevers shows
> >
> >
> > This is a stab in the dark, but maybe the problem is not with
> > session_start.
> > Maybe session_start uses/calls something else which has a negative
> > impact on
> > your system. So.... you may be addressing the issue, but from the
> wrong
> > angle??
> >
> >
> >
> > > Thanks
> > >
> > > Mathieu Dumoulin
> >
> >
> >
> > Well, I gave you a lot of useless information, but hopefully it
> sparks
> > a
> > fire! =D Good Luck.
> >
> > ~Philip
> 
> I don't think there's a name clash in session file names... session
> identification is based on a browser cookie if I remember well
> PHPSESSIONID,
> and so are file names which (again, if my memory is right) are called
> "sess_<session_id>" where <session_id> is the aforementioned cookie.
> Cookies are different for different (sub)domains... so, the browser
> won't
> send the session cookie for "www.domain.com" to "dev.domain.com"...
> meaning
> both subdomains should get different session ids and session files
> (which
> cannot clash because the session id is generated randomly using an MD5
> hash,
> right?).
> I would say the problem is at some point in the IIS-PHP communication.
> Maybe
> the browser is sending the session ID to the server, the server gets
> the
> session id, and when you use "session_start" it tries to grab the file
> which
> is locked (for some extrange and unknown windows reason as usual) and
> then
> it hangs waiting for the file to be available.
> 
> I don't know if this will be of any help for you, but I'd locate the
> session
> files directory (the location can be found in PHP.INI) and delete every
> file
> in there, and if possible restart the webserver.
> Also, there's a debugging tool in the IIS 6.0 resource kit that can be
> used
> to log and/or point out problems in the IIS worker processes (can't
> remember
> its name, I had to deal with that about two years ago). That will at
> least
> give you some use(ful|less) information about which process is
> faulting,
> what's the exception and which is the code causing the fault. If
> there's any
> fault of course... if it's only a deadlock, it might provide no useful
> information, because the IIS process would simply be waiting for the
> session
> file to be available for read(write).
> 
> Ok... this was just another bit of probably useless information... but
> someone will help us out, I know.
> 
> Rob
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux