Quantcast

LONG_POLL when clicking on browse items & categories

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

LONG_POLL when clicking on browse items & categories

Dean Junk

While trying to debug my reverse proxy with ssl to misterhouse, I noticed in the developer console under network, LONG_POLL is called repeatedly on the browse items and categories pages. The only way to make it stop is to browse off of those pages. At first I thought it might be my reverse proxy setup, but I also saw the same behavior when accessing misterhouse directly using normal http. The pages are displayed immediately, but the call to LONG_POLL seems infinite.


Bug or feature?


Thanks!


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LONG_POLL when clicking on browse items & categories

H Plato
Probably a feature. That’s how the ‘IA7 Server push' design works, a long_poll is generated which keeps the connection open until new data arrives, or the connection times out. The javascript on the page processes the data, and then calls it again.

It could be a ‘bug’, since the downside of this approach causes more CPU cycles for the MH process as json_server constantly checks if new data is available to push to the client.


On Mar 12, 2017, at 12:24 PM, Dean Junk <[hidden email]> wrote:

While trying to debug my reverse proxy with ssl to misterhouse, I noticed in the developer console under network, LONG_POLL is called repeatedly on the browse items and categories pages. The only way to make it stop is to browse off of those pages. At first I thought it might be my reverse proxy setup, but I also saw the same behavior when accessing misterhouse directly using normal http. The pages are displayed immediately, but the call to LONG_POLL seems infinite.

Bug or feature?

Thanks!
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LONG_POLL when clicking on browse items & categories

Dean Junk
I think it's a bug since on all other pages you see the long poll executed every so often if you let the page be idle, but on these pages you can barely read a line on the network tab since long poll is being called so often.
 
On 3/12/17 3:58 PM, [hidden email] wrote:
Probably a feature. That’s how the ‘IA7 Server push' design works, a long_poll is generated which keeps the connection open until new data arrives, or the connection times out. The javascript on the page processes the data, and then calls it again.

It could be a ‘bug’, since the downside of this approach causes more CPU cycles for the MH process as json_server constantly checks if new data is available to push to the client.


On Mar 12, 2017, at 12:24 PM, Dean Junk <[hidden email]> wrote:

While trying to debug my reverse proxy with ssl to misterhouse, I noticed in the developer console under network, LONG_POLL is called repeatedly on the browse items and categories pages. The only way to make it stop is to browse off of those pages. At first I thought it might be my reverse proxy setup, but I also saw the same behavior when accessing misterhouse directly using normal http. The pages are displayed immediately, but the call to LONG_POLL seems infinite.

Bug or feature?

Thanks!
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LONG_POLL when clicking on browse items & categories

H Plato
I think I see what you mean. A page like this:


Generates about 6 - 10 requests a second from my server.

So, yes that probably a bug. It’s been this way since the prototype, but definitely this could be looked at to only send data back when the requested data changes. I’m guessing this returns right away on all calls since at least one object in MH meets these conditions all the time:

        if ( !( $object->can('get_idle_time') ) ) {

            #Items that do not have an idle time do not get reported at all in updates
            return;
        }
        elsif ( $object->get_idle_time eq '' ) {

            #Items that have NEVER been set to a state have a null idle time
            return;
        }
        elsif  (( $request_time - 1 ) > ( $current_time - $object->get_idle_time ) )
        {

            #To avoid missed changes, since they can happen at the millisecond level, give a second's cushion
            #Object has not changed since time, so return undefined
            return;
        }

json_server optimization should be on the todo list for 4.3. It would be great to fix this, and to reduce the CPU overhead of the json_server polling.


On Mar 12, 2017, at 3:28 PM, Dean Junk <[hidden email]> wrote:

I think it's a bug since on all other pages you see the long poll executed every so often if you let the page be idle, but on these pages you can barely read a line on the network tab since long poll is being called so often.
 
On 3/12/17 3:58 PM, [hidden email] wrote:
Probably a feature. That’s how the ‘IA7 Server push' design works, a long_poll is generated which keeps the connection open until new data arrives, or the connection times out. The javascript on the page processes the data, and then calls it again.

It could be a ‘bug’, since the downside of this approach causes more CPU cycles for the MH process as json_server constantly checks if new data is available to push to the client.


On Mar 12, 2017, at 12:24 PM, Dean Junk <[hidden email]> wrote:

While trying to debug my reverse proxy with ssl to misterhouse, I noticed in the developer console under network, LONG_POLL is called repeatedly on the browse items and categories pages. The only way to make it stop is to browse off of those pages. At first I thought it might be my reverse proxy setup, but I also saw the same behavior when accessing misterhouse directly using normal http. The pages are displayed immediately, but the call to LONG_POLL seems infinite.

Bug or feature?

Thanks!
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users




------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LONG_POLL when clicking on browse items & categories

Dean Junk
Yes, that is exactly what I was seeing.

On 3/12/17 7:37 PM, H Plato wrote:
I think I see what you mean. A page like this:


Generates about 6 - 10 requests a second from my server.

So, yes that probably a bug. It’s been this way since the prototype, but definitely this could be looked at to only send data back when the requested data changes. I’m guessing this returns right away on all calls since at least one object in MH meets these conditions all the time:

        if ( !( $object->can('get_idle_time') ) ) {

            #Items that do not have an idle time do not get reported at all in updates
            return;
        }
        elsif ( $object->get_idle_time eq '' ) {

            #Items that have NEVER been set to a state have a null idle time
            return;
        }
        elsif  (( $request_time - 1 ) > ( $current_time - $object->get_idle_time ) )
        {

            #To avoid missed changes, since they can happen at the millisecond level, give a second's cushion
            #Object has not changed since time, so return undefined
            return;
        }

json_server optimization should be on the todo list for 4.3. It would be great to fix this, and to reduce the CPU overhead of the json_server polling.


On Mar 12, 2017, at 3:28 PM, Dean Junk <[hidden email]> wrote:

I think it's a bug since on all other pages you see the long poll executed every so often if you let the page be idle, but on these pages you can barely read a line on the network tab since long poll is being called so often.
 
On 3/12/17 3:58 PM, [hidden email] wrote:
Probably a feature. That’s how the ‘IA7 Server push' design works, a long_poll is generated which keeps the connection open until new data arrives, or the connection times out. The javascript on the page processes the data, and then calls it again.

It could be a ‘bug’, since the downside of this approach causes more CPU cycles for the MH process as json_server constantly checks if new data is available to push to the client.


On Mar 12, 2017, at 12:24 PM, Dean Junk <[hidden email]> wrote:

While trying to debug my reverse proxy with ssl to misterhouse, I noticed in the developer console under network, LONG_POLL is called repeatedly on the browse items and categories pages. The only way to make it stop is to browse off of those pages. At first I thought it might be my reverse proxy setup, but I also saw the same behavior when accessing misterhouse directly using normal http. The pages are displayed immediately, but the call to LONG_POLL seems infinite.

Bug or feature?

Thanks!
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users





------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Loading...