Hey,
If your web app is going to have some pretty serious usage you might consider
get rid of apache (for the long polling part specifically) and take a look to
nginx+http_push_module :-)
On 09/02/2011, at 22:32, Gareth McCumskey <gmccums...@gmail.com> wrote:
> I figured it was something server related either session (which we determined
> was the case) or the actual web server configuration (as was the case) as any
> framework that doesn't allow concurrent requests would be essentially
> useless. Imagine developing an application only one user at a time could use
> >.<
>
> On 09/02/2011 23:23, Gabriele Genta wrote:
>>
>> I finally pointed out the problem, and it has nothing to do with symfony,
>> nor the server configuration. The problem was on the client side of the
>> application: I'm developing it with Sproutcore, and using their development
>> server (sc-server) to test it; unfortunately, sc-server does not support
>> concurrent requests. So I'll have to fall back to a good old standard
>> polling mechanism until they fix the issue (and hoping that they
>> would).
>> Thanks Gareth for your help, really appreciate it. By the way, this gave me
>> a good knowledge of session file locking problems and solutions, which could
>> be handy in future :)
>>
>> Gabriele
>> On mercoledì 9 febbraio 2011 at 19.35, Gareth McCumskey wrote:
>>
>>> Well, in that case, have you verified that your web server is configured
>>> correctly? Is it perhaps set to only allow one process or connection at a
>>> time which would cause your queuing problem? Typically Apache should be
>>> able to handle very many child processes but often this setting can
>>> mistakenly be altered thinking its a load saving technique.
>>>
>>> On 09/02/2011 15:46, Gabriele Genta wrote:
>>> 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
>>>
>>> -- 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
