Ok then, following your advice I found a more canonical way of handling the
problem without forcing the framework. To do so I configured symfony so that a
session is not started automatically and I've also told it to use the
ArraySessionStorage in place of the native one. As a result, now the
application never calls the php functions for session handling (session_*), and
no session file/record is created at all when the backend is invoked.
Nevertheless the problem is still occuring, so at this stage I think it isn't
related to session locks at all.
Thanks,
Gabriele
On mercoledì 9 febbraio 2011 at 14.13, Gareth McCumskey wrote:
> With symfony 1 you cannot use session_write_close reliably. There is a
> specific symfony function you call on the sfUser object to actualy have it
> close properly ;) Thats why I linked my blog post to help with that info.
>
> On Wed, Feb 9, 2011 at 3:04 PM, Gabriele Genta <gabriele.ge...@gmail.com>
> wrote:
> > Thanks Garreth for your response. As I pointed out in my original post,
> > though, I already tried the fixes regarding session files locking by
> > calling session_write_close() and also by discarding session saving at all,
> > by doing something like this:
> >
> > function foo() {}
> > session_set_save_handler("foo", "foo", "foo", "foo", "foo", "foo");
> >
> > Anyway, none of them worked, there's still something preventing the
> > requests from running.
> > Thanks anyway,
> >
> > Gabriele
> >
> > On mercoledì 9 febbraio 2011 at 12.10, Gareth McCumskey wrote:
> > > The problem is session write locking. We had the same issue in symfony 1.
> > > I don't know how to do this for symfony 2 but I wrote a blog post to deal
> > > with it in symfony 1. Perhaps you can just convert this for use with
> > > symfony 2:
> > >
> > > http://garethmccumskey.blogspot.com/2009/10/php-session-write-locking-and-how-to.html
> > >
> > > On Wed, Feb 9, 2011 at 1:07 PM, Gabriele Genta
> > > <gabriele.ge...@gmail.com> wrote:
> > > > Hello,
> > > > I'm trying to implement long polling in a Synfony 2 project to shorten
> > > > response times in a "real-time" application I'm making. Essentially I
> > > > have an ajax front end that requests data to the symfony-driven backend
> > > > through XHR. My problem arises when I try to send a second request to
> > > > the backend while a first one is on hang for long polling; the second
> > > > request just get queued after the first, and doesn't get processed
> > > > until the first returns.
> > > > I've googled a bit about the problem and found out that it could
> > > > depend on session files being locked (see here:
> > > > http://stackoverflow.com/questions/1430883/simultaneous-requests-to-php-script)
> > > > during requests, but getting rid of session files didn't help (my
> > > > backend is completely stateless, so it doesn't need sessions at all
> > > > actually).
> > > > Has anyone come across this problems before? I think the problem might
> > > > have to do with symfony and caching (setting locks on cache files
> > > > during requests, maybe?), but I don't know enough of the guts of
> > > > symfony itself to find a solution or a workaround..
> > > > Thanks a lot!
> > > >
> > > > Gabriele Genta
> > > >
> > > > --
> > > > If you want to report a vulnerability issue on symfony, please send it
> > > > to security at symfony-project.com
> > > >
> > > > You received this message because you are subscribed to the Google
> > > > Groups "symfony users" group.
> > > > To post to this group, send email to symfony-users@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > symfony-users+unsubscr...@googlegroups.com
> > > > For more options, visit this group at
> > > > http://groups.google.com/group/symfony-users?hl=en
> > >
> > > --
> > > Gareth McCumskey
> > > http://garethmccumskey.blogspot.com
> > > twitter: @garethmcc
> > > identi.ca: @garethmcc
> > >
> > > --
> > > If you want to report a vulnerability issue on symfony, please send it
> > > to security at symfony-project.com
> > >
> > > You received this message because you are subscribed to the Google
> > > Groups "symfony users" group.
> > > To post to this group, send email to symfony-users@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > symfony-users+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > > http://groups.google.com/group/symfony-users?hl=en
> > --
> > If you want to report a vulnerability issue on symfony, please send it to
> > security at symfony-project.com
> >
> > You received this message because you are subscribed to the Google
> > Groups "symfony users" group.
> > To post to this group, send email to symfony-users@googlegroups.com
> > To unsubscribe from this group, send email to
> > symfony-users+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/symfony-users?hl=en
>
>
> --
> Gareth McCumskey
> http://garethmccumskey.blogspot.com
> twitter: @garethmcc
> identi.ca: @garethmcc
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony users" group.
> To post to this group, send email to symfony-users@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-users+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-users?hl=en
>
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
