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

Reply via email to